Issue Details (XML | Word | Printable)

Key: CORE-6339
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Adriano dos Santos Fernandes
Votes: 0
Watchers: 4
Operations

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

Detach server from security database when missing plugin data structures cause an error

Created: 22/Jun/20 11:21 AM   Updated: 09/Jul/20 03:11 PM
Component/s: None
Affects Version/s: 4.0 Beta 1, 3.0.5, 3.0.6
Fix Version/s: 4.0 RC 1, 3.0.7

QA Status: No test


 Description  « Hide
If server is open, it's using security database and one cannot attach to it with embedded.

It would be good if server detaches from security when it cannot use, so the server will not be needed to be closed to create the user with embedded.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Karol Bieniaszewski added a comment - 22/Jun/20 01:00 PM
sorry for oftopic
but what is the usage case?
Embeded should use separate "instalation" not the same as regular server, then different security db.

Alexander Peshkov added a comment - 22/Jun/20 01:27 PM
You are wrong, Karol, embedded can be used in the same installation as network server. To be precise - network server is (from databases access POV) nothing except client of embedded.

Sean Leyne added a comment - 22/Jun/20 02:23 PM
I with Karol, you seem to be mixing access from 2 different types of clients.

Why would it be necessary for remote server to detach security database?

If the remote security database is open by another instance, then that instance responsible for the management of the users. It is not appropriate for a remote embedded client to be able to take over management of the remote instance.

Please provide a use case.

Alexander Peshkov added a comment - 22/Jun/20 02:40 PM
When one is manually initializing security database extracted from windows zip package.

Sean Leyne added a comment - 22/Jun/20 03:18 PM
It seems that are proposing to change default logic to handle (i) an edge use case, or (ii) a problem with a full install that should not require the use of embedded client to resolve. In either case, the change seems an inappropriate solution.

Mark Rotteveel added a comment - 22/Jun/20 04:05 PM - edited
The 'cannot use' condition seems to be quite specific to the 'security database not initialized for SRP' problem. However if legacy_auth is enabled on the server, and a client attaches with only legacy_auth in the list of plugins (or as the first plugin, or connecting with protocol v12 or lower), they will have no problem with attaching to the server. So, if such operations interleave, you will have inconsistent behavior, because:

Scenario 1 (succeeds)

1. connect with SRP fails
2. detach security database
3. attach with embedded -> success

Scenario 2 (fails)

1. connect with SRP fails
2. detach security database
3. connect with legacy_auth succeeds (security db reattached)
4. attach with embedded -> fails

Scenario 3 (fails)

1. connect with SRP fails
2. detach security database
3. attach with embedded
4. connect with legacy_auth -> fails (because database in use by embedded)
(though this scenario might be very sensitive to timing)

These scenarios would also apply to other cases with multiple plugins and clients specifying a different mix of plugins when connecting.

An alternative would be to open the security database as ThreadedShared (SuperClassic), but that would allow for the potential for problems if the embedded process is misconfigured (ie lockfiles in a different location).

Alexander Peshkov added a comment - 23/Jun/20 09:32 AM
Sean & Mark, must say I did not expect that this simple and causing no harm fix can burn so big flame :-)

May be that's because of my bad English, i.e. I badly explained what actually happens. Authentication plugin can't forcibly close any database - it can only make sure that there are no connects from it to that database. To be precise keeping such attachments (which anyway can't be used for authentication) in plugin's cache was a bug and from that POV this is even not an improvement but bugfix. Next fact taken into an account is use of linger (60 sec in default case) for security db. In order to avoid that 60 sec delay before completely releasing security3.fdb file authentication plugin turns off the linger, but certainly not permanently, linger will not take place only once (exactly like gfix -nolinger works).

Also please pay attention that far not any error with SRP causes described behavior - only isc_missing_data_structures error triggers linger off. I.e. there is no change in default logic, logic was changed only in a case of specific error and this fix is only a handler of that error, not a part of default logic. Therefore it does not cause any problem with full install - mentioned error does not take place, therefore handler is not activated.

An aim of improvement was to help people (beginners! - experienced user knows well himself what to do) deal with edge case as simple as possible. What about 3 scenarios - please pay attention that 2 & 3 require presence of legacy authentication, i.e. modified configuration. That's hardly a case for beginner. But even in that case there is actually no harm. In scenario 2 one will need to go old way, described in documentation - temporarily stop server. I insist that this is not too big problem when configuration was already modified manually. Scenario 3 really can cause problems with legacy authentication attachments for a few milliseconds, that time is hardly comparable with stopping server for a while.

@mark - suggested alternative can not be implemented with existing engine, we still can not open specific database in a mode different from global one.