Issue Details (XML | Word | Printable)

Key: CORE-3368
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Alexander Peshkov
Votes: 3
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Make it possible to specify non-default security database for specific database

Created: 02/Mar/11 01:26 PM   Updated: 23/Sep/15 12:17 PM
Component/s: Engine, GSEC, Security
Affects Version/s: None
Fix Version/s: 3.0 Beta 1

Issue Links:
Relate

Sub-Tasks  All   Open   

 Description  « Hide
It was requested many times and in different form (including some requests in this tracker) to make it possible to have separate users' lists for different databases, including different SYSDBA's passwords and ability to store users' list inside database itself.

The solution should be based on already existing per-database configuration in aliases.conf. New config parameter SecurityDatabase is supposed to do that trick:
alias = /path/to/database.fdb
{
  SecurityDatabase = alias_or_database_name
}



 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 02/Mar/11 06:22 PM
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.

Dmitry Yemanov added a comment - 02/Mar/11 06:42 PM
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?

Sean Leyne added a comment - 02/Mar/11 06:59 PM
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!

Alexander Peshkov added a comment - 03/Mar/11 08:00 AM - edited
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.

Sean Leyne added a comment - 03/Mar/11 04:11 PM
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.

Alexander Peshkov added a comment - 04/Mar/11 12:00 PM
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.


Dmitry Yemanov added a comment - 04/Mar/11 12:42 PM
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.

Dmitry Yemanov added a comment - 04/Mar/11 12:42 PM
Guys, the tracker is not a good place for this discussion, so let's continue (if required) in fb-devel.

Sean Leyne added a comment - 04/Mar/11 04:36 PM
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.