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

Unable to connect with database if security.db reference is removed from databases.conf file [CORE6230] #6474

Closed
firebird-automations opened this issue Jan 15, 2020 · 9 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @luronumen

Block progress on CORE6072

ACTUAL RESULT
- Unable to connect with any database if security.db reference is removed from databases.conf file
- <I/O error during "CreateFile (open)" operation for file "security.db"> error message is displayed when is trying to create or alter users (e.g.: CREATE OR ALTER USER SYSDBA SET PASSWORD 'blablabla' USING PLUGIN LEGACY_USERMANAGER;

EXPECTED RESULT
- The Firebird engine should consider the $(dir_secDb)/security3.fdb as your default security.db when it is not included on databases.conf file;
- The end user should be able to connect with any database security.db reference is not on databases.conf file;
- No error should be happen when is trying to create or alter users;

IMPORTANT NOTES:
- This issue did NOT happen with the Firebird 3.0.4 (Regression issue)

===Default security.db reference from databases.conf file===
security.db = $(dir_secDb)/security3.fdb
{
RemoteAccess = false
DefaultDbCachePages = 50
}

Commits: d39f26a 53faf9e

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Why did you not provide a comment from databases.conf before mentioned section:

#⁠
#⁠ Master security database specific setup.
#⁠ Do not remove it until you understand well what are you doing!
#⁠

If you really need to remove security.db from databases.conf just add
SecurityDatabase = $(dir_secDb)/security3.fdb
to firebird.conf and an issue will be gone.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

Link: This issue block progress on CORE6072 [ CORE6072 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

There is no correct dependency in the tracker - CORE6230 _conflicts_ with CORE6072.

With explicit (not alias) name of default security database use of multiple providers is impossible.

@firebird-automations
Copy link
Collaborator Author

Commented by: @luronumen

Hi Alexander Peshkov,

This issue was raised first because it did not happen in the previous Firebird version (3.0.4) and second because good software practices suggest that configuration files be used to modify the default software behavior but not to setup everything. An example of this is the Firebird port configuration itself where if the user does not set it in Firebird.conf then port 3050 is automatically used.

Beside that, it would be important that the databases.conf file had a high backward compatibility with the old aliases.conf file facilitating migration from version 2.5 to version 3.0.

Based on your comment I believe the best solution for this issue would be for Firebird to consider "SecurityDatabase = $ (dir_secDb) /security3.fdb" every time it finds no reference to it in the firebird.conf and databases.conf files.

Best Regards,
Luciano

@firebird-automations
Copy link
Collaborator Author

Commented by: @luronumen

Retest result on Firebird 3.0.5.33220 (Official Firebird 3.0.5): - FAILED (#⁠motorolablocker)

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Have you seen it's marked as fixed? Why do you expect other result? ;)

Getting serious we have 2 options.
1. Keep it as is forcing people using non-default-based databases.conf add a few lines to it or firebird.conf.
2. Modify code in a way that does not require any mention of security.db in .conf files but makes it necessary to add some changes to firebird.conf in multiprovider case.

I still do not know what is less evil.
BTW, missing security.db description in databases.conf is not good from security POV (enabled access to that DB from network) and resources usage on SS (server wastes RAM in that db cache).

@firebird-automations
Copy link
Collaborator Author

Commented by: @luronumen

Hi Alexander Peshkov,

Thank you very much for your prompt reply!
In my humble opinion I think that Firebird should not depend on customizations of the databases.conf file to work just as it did not on Firebird 2.5.9. The databases.conf file should only be used to configure the conditions of access to the customer's database.
Yes, un-commenting the line "SecurityDatabase = $(dir_secDb)/security3.fdb" in the firebird.conf file the issue is not reproducible and my point of this issue is just that it should be the default Firebird 3.0.5 behavior (without need to un-comment that line) like it was on Firebird 3.0.4.
For now, I will use this workaround for not face this issue.

Best Regards,
Luciano

firebird.conf
#⁠ ----------------------------
#⁠ Security database
#⁠
#⁠ Defines locations of security database (one that stores logins and passwords),
#⁠ used by server to validate remote connections.
#⁠
#⁠ Per-database configurable.
#⁠
#⁠ Type: string (pathname)
#⁠
#⁠SecurityDatabase = $(dir_secDb)/security3.fdb

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

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

resolution: Fixed [ 1 ]

Fix Version: 4.0 Beta 2 [ 10888 ]

Fix Version: 3.0.6 [ 10889 ]

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