Verify difference file path against DatabaseAccess

[caolanm]

The difference file opened in openDelta and beginBackup is not verified against DatabaseAccess, unlike the other database file paths. This looks like an oversight, presumably the setting is meant to cover every file the engine opens by path. Found while using the embedded engine from LibreOffice.

[hvlad]

Hmm... why do you think difference file placement must be verified exactly this way, i.e. against DatabaseAccess ?
Do you want, for example, backup files placement to be verified also ? Note, physical backup of level 0 is the database copy.

[hvlad]

presumably the setting is meant to cover every file the engine opens by path

Not agree, sorry

[caolanm]

LibreOffice, optionally, supports embedded firebird databases so we'd like to not allow arbitrary dbs, that a user might receive from someone else, to specify what file paths they backup to and the LibreOffice firebird save
is via the backup mechanism.

[AlexPeshkoff]

On 7/14/26 01:48, Caolán McNamara wrote: *caolanm* left a comment (FirebirdSQL/firebird#9089) <#9089 (comment)> LibreOffice, optionally, supports embedded firebird databases so we'd like to not allow arbitrary dbs, that a user might receive from someone else, to specify what file paths they backup to and the LibreOffice firebird save is via the backup mechanism.

Wider look at the problem is needed here. Yes, for embedded case this seems to be useful, but take into an account large dedicated server. From performance POV difference file should better be saved on separate HW device which will sooner of all be mounted at some other location. As the first sample this may be /tmp - which is hardly included into DatabaseAccess. I agree with your requirements for LibreOffice but suppose we need something smarter.

[hvlad]

LibreOffice, optionally, supports embedded firebird databases so we'd like to not allow arbitrary dbs, that a user might receive from someone else, to specify what file paths they backup to and the LibreOffice firebird save is via the backup mechanism.

LibreOffice might issue ALTER DATABASE ADD DIFFERENCE FILE <filename> or 'ALTER DATABASE DROP DIFFERENCE FILE' whenever it opens such "foreign" database or before physical backup start.

See https://www.firebirdsql.org/file/documentation/html/en/firebirddocs/nbackup/firebird-nbackup.html#nbackup-deltafile

[caolanm]

LibreOffice might issue ALTER DATABASE ADD DIFFERENCE FILE <filename> or 'ALTER DATABASE DROP DIFFERENCE FILE' whenever it opens such "foreign" database or before physical backup start.

  #0 BackupManager::writeDifference  diff_page=3                               nbak.cpp:862
  #1 write_page                                                                cch.cpp:4969
  #2 write_buffer                                                              cch.cpp:4848
  #3 CCH_release                                                               cch.cpp:1949
  #4 transaction_start                                                         tra.cpp:3335
  #5 TRA_start                                                                 tra.cpp:1714
  #6 JProvider::internalAttach                                                 jrd.cpp:1919
  #7 JProvider::attachDatabase
  ...
  #13 isc_attach_database

In an already existing db load case it seems to be too late to call ALTER DATABASE, the difference file is already written during the attach

[hvlad]

If database is in backup state already - sure, it is too late to change delta file placement.
My suggestion was about databases that controlled by LO.

[caolanm]

What happens with these embedded databases is that a backup-format fdb is packaged into a wrapper .odb LibreOffice "Base" file, so LibreOffice can be presented with an arbitrary, potentially untrustworthy, fdb. Which is why I was reaching at DatabaseAccess, which seemed to give the kind of restrictions that would be useful there.

[hvlad]

What happens with these embedded databases is that a backup-format fdb is packaged into a wrapper .odb LibreOffice "Base" file, so LibreOffice can be presented with an arbitrary, potentially untrustworthy, fdb.

How that untrustworthy database become packaged into a wrapper .odb ?
By miracle ?
Or by some code that could do any checks you need ?

If you need help or advise how to do such checks or anything else related with Firebird usage - just explain your problem and ask.

Which is why I was reaching at DatabaseAccess, which seemed to give the kind of restrictions that would be useful there.

This is wrong way, sorry. You want to make all users of Firebird to follow artificial restriction that solve no issue for Firebird users.

[aafemt]

How that untrustworthy database become packaged into a wrapper .odb ?

Taking into account that it is just a ZIP archive - however the malefactor wants, including modification of LO sources.