Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make it possible to specify non-default security database for specific database [CORE3368] #3734

Closed
firebird-automations opened this issue Mar 2, 2011 · 18 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @AlexPeshkoff

Jira_subtask_outward CORE3369
Jira_subtask_outward CORE3370
Is related to CORE685
Jira_subtask_outward CORE3372
Relate to CORE848

Votes: 3

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
}

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

Link: This issue replaces CORE848 [ CORE848 ]

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

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?

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is related to CORE685 [ CORE685 ]

@firebird-automations
Copy link
Collaborator Author

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!

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

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

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue relate to CORE848 [ CORE848 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue replaces CORE848 [ CORE848 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Beta 1 [ 10332 ]

Fix Version: 3.0 Alpha 1 [ 10331 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants