Commented by: Sean Leyne (seanleyne)

How will this address the issue of the storing user credentials inside of the database?

This approach requires that the database security be configured for this "mode" thru an external config. I do not think that this is what users want.

They want to have the "security mode" of the database stored within the database itself (the header logically) so that the mode cannot be bypassed thru some external configuration setting. Otherwise, there is no real security to the database.

Commented by: @dyemanov

Sean, there are different kind of users and some of them don't need an embedded security but they do need to have users stored inside the database itself (for management purposes).

As for the "security mode" of the database, why cannot it be addressed by encryption?

Commented by: Sean Leyne (seanleyne)

The "security mode" has nothing to do with encryption.

The proposed usage of the external config files to define what are basic database settings has started us on a road where the ease of maintenance, configuration and database portability has been lost.

More config details need to be stored within the database itself without the need for an external config (just one file/more thing to get buggerred up!)

The fact that the security database is setup to use Active Directory (and what Domain is it "bound to") or embedded security tables or using some other method should intrinsic (stored inside the database) to the database!

Commented by: @AlexPeshkoff

Sean, what kind of protection do you suggest to achieve storing security settings in database header? I see absolutely no difference from security POV between that settings stored inside database or in configuration file.

Commented by: Sean Leyne (seanleyne)

Alex, first you don't need to remember the settings if the database is relocated.

Second, aside from someone hacking the header page, one would expect that the ability to change the header page (via the engine) would require that a puser have credentials to open/attach the database. Thus, creating a much higher "bar/hurdle" should someone try to "steal" the database information, including the database schema -- consider commercial software deployed to independent locations. If all someone has to do is to change a config file, then that's easy as pie.

Commented by: @AlexPeshkoff

If database is relocated, you will anyway have to change it's path in aliases.conf. After it SecurityDatabase seting will work correctly.

What about the problem of stealing database.
Protection of database from it is absolutely unrelated with where you keep this setting. Moreover, it's absolutely unrelated with method of logging to server, including use of ActiveDirectory. If someone has stolen database as a file, he can always use embedded access to it, when no password is required at all. Any attempt to disable embedded access is useless for open source software - disabling a check is the surces is trivial.

The only correct way to protect database from being stolen is use of correct filesystem-level access rights, something like:
-rw-rw---- 1 firebird firebird .......... database.fdb
BTW, by default our engine creates databases with this access rights. Try to steal it, specially taking into an account that user firebird can't login himself when created by out setup script.

Commented by: @dyemanov

1) Ease of relocation. If every database has its local settings stored aside (in the same directory) and #⁠included into firebird.conf / aliases.conf, then it won't be any harder than now. Or just copy your aliases.conf and adjust its settings (it will be needed anyway, unless you use full pathnames as connection strings).

2) Local vs global configuration. Even if a database has some local settings (be it embedded or located in the configuration file), it's quite arguable what settings should be honored. It's the server administrator who has full control over the database, so it's quite logical that he can override any local settings with global configuration. Just imagine a "clever" developer tuning the database for high-end performance but installed on a web hosting site that handles thousands databases and simply cannot afford to follow the local settings thus having to limit them via the global configuration.

3) Stolen database. As Alex has already mentioned, it's quite pointless to protect it with an embedded "security mode". Encryption seems being a better solution here.

Commented by: @dyemanov

Guys, the tracker is not a good place for this discussion, so let's continue (if required) in fb-devel.

Commented by: Sean Leyne (seanleyne)

I agree that the tracker is not the best place to discuss these items.

However, I have a problem with cases like this being created without any public discussion. Certaintly, when the case details suggest that the item is under active development.