Re: [HACKERS] User authentication bug?

From: Maarten Boekhold <maartenb(at)dutepp2(dot)et(dot)tudelft(dot)nl>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: M(dot)Boekhold(at)ITS(dot)TUDelft(dot)NL, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] User authentication bug?
Date: 1998-07-31 20:05:40
Message-ID: Pine.SUN.3.91.980731215821.8652A-100000@dutepp2.et.tudelft.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 31 Jul 1998, Bruce Momjian wrote:

> > Hi,
> >
> > I was having trouble with user authentication, so I submerged myself in
> > the source (UTSL ie. Use The Source luke ;) to see if I could figure out
> > what I was doing wrong:
> >
> > While using passwords stored in pg_shadow (pg_user), I cannot connect to
> > the backend using the 'password' authentication, I can connect using 'crypt'.
> >
> > Now, I found from the source that the routines that do crypt checking
> > also seem to support plain passwords. But this code is never used,
> > because apparently uaCrypt is never set for 'password', while my
> > understanding is that this should be set when there is no password-file
> > specified in pg_hba.conf.
> >
> > AlthoughcCheckPassword() seems to provide for this, it appears not to be
> > working.
> >
> > Anybody knows what's going on here? I intent to fire up a debugger here
> > to see if I can figure out what's wrong, but thought asking first doesn't
> > do any harm.

OK, I now know what's going on, at least at my home (I had this problem
on another server, dunno if it's caused by the same thing):

I had a password longer than 8 characters in pg_shadow.

when creating a user, postgres happily accepts more than 8 chars, and
also stores them. apparently libpq-fe (or psql, dunno) only sends 8
chars. And postgres internally (crypt_verify) also checks more than 8
chars. The password-field in pg_shadow is of type text, so it can contain
very long passwords.

2 options: either make psql/libpq-fe send more than 8 chars (don't know if
the protocol can handle it), or make the strcmp() in crypt_verify() a
strncmp().

Man, this was confusing.....

> >
> > btw. is there anywhere a good description on how control flows during
> > this phase of connecting? It all looks very difficult, with lots of
> > function pointer being passed around etc.
>
> Yes, very confusing. Only Tom Lane understands it, I think. Maybe
> Tatsuo too.

I'm so happy to know this. It means I'm not stupid. But I think I get it
just a little bit. There's a lot of handling there to be able to handle
more than 1 connection at a time, so therefore function pointers are
stored to remember were the next input packet it supposed to be handled.
IMO it would have been cleaner (ie. better readable) to have some
integer plus a dispatch routine (large switch{} statement) to do this.
Also much easier to debug I think.

Maarten

_____________________________________________________________________________
| TU Delft, The Netherlands, Faculty of Information Technology and Systems |
| Department of Electrical Engineering |
| Computer Architecture and Digital Technique section |
| M(dot)Boekhold(at)et(dot)tudelft(dot)nl |
-----------------------------------------------------------------------------

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-08-01 01:20:15 Re: [HACKERS] OR clause status report - working
Previous Message Bruce Momjian 1998-07-31 19:53:25 Re: [HACKERS] User authentication bug?