On 25-2-2019 15:05, Alex Peshkoff via Firebird-devel wrote:
On 2/25/19 4:45 PM, Mark Rotteveel wrote:
On 25-2-2019 13:51, Alex Peshkoff via Firebird-devel wrote:
On 2/24/19 10:52 AM, Mark Rotteveel wrote:
The security database inside the distribution is already initialized
with a Legacy_Auth SYSDBA only. I'm not sure why the same can't be
done for SRP (or at least: isn't done for SRP).
First half of an answer is very simple - in order to avoid network
server running with SYSDBA/masterkey login in default configuration.
Looking at this discussion I once again notice that this protection
is rather efficient :)
Then lets change this question to why the security database in the
distribution isn't initialized for SRP (ie having the PLG$SRP table,
maybe other things needed). Would it be possible to initialize it as
part of the distribution **without** having a user present? That at
least would avoid the "Look at the compatibility chapter" error.
It will be very useful for a user which started to change configuration
file not understanding it to read an instruction instead of continuing
in random order.
Once again - if one includes SRP in configuration security DB should
contain at least one SRP user, if there are no users why include it at all?
Because otherwise, if you try to login with Legacy_Auth, while the
default order tries Srp first, you get an error. And instead of
continuing the authentication process with the next plugin, the process
ends. I don't think that is the right approach. Either the default
security database should be created in such a way that SRP does not
fail, **or** failures like this should just continue with the next
available plugin.
There can be all kinds of reasons for this, including wanting to be able
to use both Srp and Legacy_Auth, but starting your server without having
added a Srp user yet, and then not being able to login at all (not even
with the Legacy_Auth SYSDBA), that is extremely confusing if you are not
familiar.
Yes, **I** know how to fix this, because I have been bitten enough by it
during the testing of Firebird 3 that I automatically set things
correctly when installing a clean version (because I need both Srp and
Legacy_Auth for my testing).
But this is ultimately something that affects the usability of Firebird
when you start with it.
The assumption in how it currently works (and, IMO, the instructions in
the release notes), is based too much on the assumption that you use
either Legacy_Auth or Srp, and not a combination. It also seems to be
predicated on an assumption that the `AuthClient` setting in the
`firebird.conf` of the server is also used for the client, which is
definitely not the case on Windows, and probably also not on Linux.
And given the default security database does contain a legacy auth
with SYSDBA/masterke it is insecure anyway for people who'll enable
Legacy_Auth.
If anyone himself changed configuration to include legacy plugin he
definitely gets insecure configuration. Certainly I talk about default
configuration which was already mentioned explicitly.
This discussion is in the context of having enabled Legacy_Auth in the
installer (or otherwise), so of course my assumption includes Legacy_Auth.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
