prevent mutiple engine access to same database file

[EPluribusUnum]

In firebird.conf it should be possible to define which access methods are allowed/disabled.

e.g.: we want to define that clients are only allowed connecting via TCP/IP (even local and embedded is disallowed).

(see https://github.com/FirebirdSQL/firebird/issues/7151 and https://github.com/FirebirdSQL/firebird/issues/7301)

[mrotteveel]

You already have options to do this:

1. Host the database on another server (or in a Docker container), not on the same machine as the clients, so there is no other option but to use a remote protocol
2. Change the firebird.conf of the client to have setting Providers = Remote.
3. Configure the file system permissions in a way that clients do not have file access, but the server does (only prevents embedded access, not XNET/local access)

Be aware that - except for 3 - these options are circumventable by a determined user (e.g. by using a different fbclient.dll, a user could still have local access, or by using a different fbclient.dll with the necessary files for embedded).

I can't think of any other options that would achieve this, so I'm curious what you have in mind.

[mrotteveel]

Note that local access still goes through the server, same as TCP/IP, so I'm not sure why you'd want to disallow that.

[EPluribusUnum]

@mrotteveel , this is a protection in engine side, not on client side. I want to force the sysadmins to use TCP/IP for connecting to the databases. (gbak script, etc...)

[mrotteveel]

What you want is not really possible, other than through the options I mentioned earlier: how would the server prohibit embedded attachments? An embedded attachment is an in-process Firebird engine that opens a database directly. Given the server is not involved, it cannot prohibit this action. Even if it you could configure this for the gbak etc tools in a specific install (e.g. through option 2), it wouldn't prevent an admin to use a different copy of Firebird to do it anyway.

That said, I guess it is a bit problematic that firebird.conf controls both the configuration of the server and of usages of the fbclient located inside the server install.

[aafemt]

Switching to SuperServer mode would help. No matter what admin does if database file is opened by Firebird server exclusively embedded engine cannot get access to it.

[mrotteveel]

Switching to SuperServer mode would help. No matter what admin does if database file is opened by Firebird server exclusively embedded engine cannot get access to it.

True, but that would require that an attachment is open by the server at all times.

[aafemt]

Not strictly required: getting "database already used" error to remote attach is unpleasant but easy to understand.

[EPluribusUnum]

@mrotteveel , embedded engine does not use firebird.conf settings? This is not a security issue access prevention, but a tool to avid database corruption using a database file via server and emedded engine concurrently.

@aafemt , thank you, we'll check.

[aafemt]

The problem is that Firebird server itself is an application that open databases in embedded mode. Disabling embedded mode you'll effectively disable Firebird server as well.

[mrotteveel]

@mrotteveel , embedded engine does not use firebird.conf settings? This is not a security issue access prevention, but a tool to avid database corruption using a database file via server and emedded engine concurrently.

Embedded mode does use firebird.conf settings, but there are two problems:

1. The settings to disable embedded through fbclient.dll in the Firebird installation directory will also prevent the Firebird server from opening the database (as Firebird server itself basically uses embedded to open the database, and it is one and the same setting, Providers)
2. Nothing can prevent anyone from using a separate Firebird installation (or unzipped zipkit) to use Firebird embedded anyway, even if you could configure the Firebird server install to disallow embedded usage by its fbclient.dll

[EPluribusUnum]

Some kind of prevention needed to avoid to use the same database file by multiple engines. Now even with a single installation could lead to multiple engine usage when connections are not defined to use TCP/IP.

[EPluribusUnum]

Renamed the issue to the real problem. (Fallen to the XY problem)

[mrotteveel]

That is basically what ServerMode = Super already achieves.

[aafemt]

Some kind of prevention needed to avoid to use the same database file by multiple engines.

No. This is exactly how Classic mode is supposed to work.

[asfernandes]

But different engines with different lock files should not access a same database. It should be possible to prevent this (considering multiple new versions with that support).

[mrotteveel]

But different engines with different lock files should not access a same database. It should be possible to prevent this (considering multiple new versions with that support).

But you're talking about different versions of the engines, OP seems to want to prevent different instances (even if it is the same version) from accessing a database.

[asfernandes]

His motivation as said is because this corrupts database but we know that it happens only when using different lock files.

I do not know if it's from the same person/team, but there is another recent issue of people thinking is using the same lock files but by some reason evidences is showing they are different.

[aafemt]

When speaking about it, is there anything that prevents lock table from residing inside of database file itself except changes in ODS required for that?

[AlexPeshkoff]

On 1/7/23 14:21, Dimitry Sibiryakov wrote:

When speaking about it, is there anything that prevents lock table from residing inside of database file itself?

Probably performance issue - people sometimes place lock table on RAM disk and looks like get performance gain. Next, it's desired to keep lock table unfragmented and be able to grow it - where do we have such space in DB file? (I know that we had code making possible to have fragmented lock file, needed for HPUX, but it's rather ugly on my mind) Last that useless pages will be in file-level backup of database.

[aafemt]

man shm_open() suggest to use path "/somename", can this trick be used instead of FB_LOCK_DIR variable?

[AlexPeshkoff]

On 1/7/23 14:45, Dimitry Sibiryakov wrote:

man shm_open() suggest to use path "/somename", can this trick be used instead of FB_LOCK_DIR variable?

yes