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
Detach server from security database when missing plugin data structures cause an error [CORE6339] #6580
Comments
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Modified by: @AlexPeshkoffreporter: Alexander Peshkov [ alexpeshkoff ] => Adriano dos Santos Fernandes [ asfernandes ] Version: 3.0.5 [ 10885 ] |
Commented by: @livius2 sorry for oftopic |
Commented by: @AlexPeshkoff 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. |
Commented by: Sean Leyne (seanleyne) 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. |
Commented by: @AlexPeshkoff When one is manually initializing security database extracted from windows zip package. |
Commented by: Sean Leyne (seanleyne) 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. |
Commented by: @mrotteveel 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 Scenario 2 (fails) 1. connect with SRP fails Scenario 3 (fails) 1. connect with SRP fails 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). |
Commented by: @AlexPeshkoff 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. |
Modified by: @AlexPeshkoffsummary: Detach server from security database on error => Detach server from security database when missing plugin data structures cause an error |
Modified by: @AlexPeshkoffVersion: 3.0.6 [ 10889 ] |
Modified by: @AlexPeshkoffstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 4.0 RC 1 [ 10930 ] Fix Version: 3.0.7 [ 10940 ] |
Submitted by: @asfernandes
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.
Commits: c0b5230 fd61284
The text was updated successfully, but these errors were encountered: