Prev: CREATE DATABASE cannot be executed from a function or multi-command string
Next: pgadmin debug on windows
From: Tom Lane on 14 Oct 2007 15:34
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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

From: Michael Glaesemann on 14 Oct 2007 16:09

On Oct 14, 2007, at 14:34 , Tom Lane wrote:

> 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.

Would there be a difference in how this is logged and how it's
reported to the user? I can see where an admin (having access to
logs) would want to have additional information such as whether a
role login has failed due to not having login privileges or whether
the failure was due to an incorrect role/password pair. I lean
towards less information back to the user as to the nature of the
failure. If the general consensus is to leave the current behavior, a
comment should probably be included to note that the behavior is
intentional.

Michael Glaesemann
grzm seespotcode net



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

From: Stephen Frost on 14 Oct 2007 16:51
* Tom Lane (tgl(a)sss.pgh.pa.us) wrote:
> 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 wonder if the OP was unhappy because he created a role w/ a pw and
then couldn't figure out why the user couldn't log in? I've run into
that in the past and it takes some leg-work to figure out what's going
on. A warning on a 'create role' or 'alter role' command which sets a
password when 'rolcanlogin' is false might be an alternative way to
'fix' this.

In general, I would say that it's correct to say 'invalid
authentication'/'bad pw' until the user is authenticated and then say
'not permitted to log in' if they're not authorized (don't have
rolcanlogin), which is I think what we do. That combined with the
warning above would, I think, cover most of problem cases.

Thanks,

Stephen
From: Tom Lane on 14 Oct 2007 16:56
Michael Glaesemann <grzm(a)seespotcode.net> writes:
> Would there be a difference in how this is logged and how it's
> reported to the user?

Not without making all the same infrastructure changes that would be
needed to tell the user something different than now. As things stand,
the password auth code can't tell the difference between a nonexistent
role and a nologin role; neither one has an entry in the flat file.
If we dropped the filtering in flatfiles.c, then a nologin role would
have an entry, but most likely without a password, so you'd still just
see "password auth failed".

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo(a)postgresql.org so that your
message can get through to the mailing list cleanly

From: Tom Lane on 14 Oct 2007 17:02
Stephen Frost <sfrost(a)snowman.net> writes:
> * Tom Lane (tgl(a)sss.pgh.pa.us) wrote:
>> ... 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 wonder if the OP was unhappy because he created a role w/ a pw and
> then couldn't figure out why the user couldn't log in?

Hm, maybe. In that case just not filtering the entry out of the flat
file would be good enough. In hindsight I'm not sure why we indulged
in that bit of complication anyway --- it seems unlikely that an
installation would have so many nologin roles, compared to regular ones,
that the increase in size of the flat file would be objectionable.

> In general, I would say that it's correct to say 'invalid
> authentication'/'bad pw' until the user is authenticated and then say
> 'not permitted to log in' if they're not authorized (don't have
> rolcanlogin), which is I think what we do.

That *would* be the behavior if we removed the filtering.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo(a)postgresql.org so that your
message can get through to the mailing list cleanly

 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: CREATE DATABASE cannot be executed from a function or multi-command string
Next: pgadmin debug on windows