There's a gripe over here
http://archives.postgresql.org/pgsql-general/2007-10/msg00640.php
to the effect that PG should not give a message like "password
authentication failure" when the user is attempting to log in as a
NOLOGIN role. This surprised me because there is a specific message
for that, and it worked when I tried it:
regression=# create user foo nologin;
CREATE ROLE
regression=# \c - foo
FATAL: role "foo" is not permitted to log in
Previous connection kept
regression=#
On investigation though, it turns out that it depends on which auth
mode you're using: some of the auth modes look up the user in the
flat password file, and some don't. Now flatfiles.c makes a point of
not entering roles into the flat password file if they are not
rolcanlogin, which means that for password auth you are guaranteed to
fail long before you can get to the explicit check in
InitializeSessionUserId.
We could certainly change flatfiles.c to disregard rolcanlogin, which'd
actually make the code simpler. However, that in itself wouldn't change
the behavior, unless you were to assign a password to the NOLOGIN role
which seems a fairly strange thing to do. I think what the OP wishes
is that "not permitted to log in" would be checked before checking
password validity, and to do that we'd have to add rolcanlogin
to the flat password file and put the check somewhere upstream of the
authentication process.
I am not entirely convinced whether we should do anything about this:
the general theory on authentication failures is that you don't say much
about exactly why it failed, so as to not give a brute-force attacker
any info about whether he gave a valid userid or not. So there's an
argument to be made that the current behavior is what we want. But
I'm pretty sure that it wasn't intentionally designed to act this way.
Comments?
regards, tom lane
