Issue Details (XML | Word | Printable)

Key: CORE-6230
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Luciano Mendes
Votes: 0
Watchers: 3
Operations

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

Unable to connect with database if security.db reference is removed from databases.conf file

Created: 15/Jan/20 04:55 PM   Updated: 07/Apr/20 09:45 AM
Component/s: Engine
Affects Version/s: 3.0.5
Fix Version/s: 4.0 Beta 2, 3.0.6

Environment:
Windows 10 x64
Firebird 3.0.5.33220 (x64)
Issue Links:
Depend
 

QA Status: No test


 Description  « Hide
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
}
======

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 15/Jan/20 05:06 PM
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.


Alexander Peshkov added a comment - 15/Jan/20 05:18 PM - edited
There is no correct dependency in the tracker - CORE-6230 _conflicts_ with CORE-6072.

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


Luciano Mendes added a comment - 15/Jan/20 05:43 PM
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

Luciano Mendes added a comment - 20/Jan/20 12:44 PM
Retest result on Firebird 3.0.5.33220 (Official Firebird 3.0.5): - FAILED (#motorolablocker)

Alexander Peshkov added a comment - 20/Jan/20 01:42 PM - edited
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).


Luciano Mendes added a comment - 20/Jan/20 02:28 PM
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