You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- 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;
- 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;
- This issue did NOT happen with the Firebird 3.0.4 (Regression issue)
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.
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).
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.
# 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