Re: [HACKERS] User authentication bug? - Mailing list pgsql-hackers
From | Maarten Boekhold |
---|---|
Subject | Re: [HACKERS] User authentication bug? |
Date | |
Msg-id | Pine.SUN.3.91.980731215821.8652A-100000@dutepp2.et.tudelft.nl Whole thread Raw |
In response to | Re: [HACKERS] User authentication bug? (Bruce Momjian <maillist@candle.pha.pa.us>) |
Responses |
Re: [HACKERS] User authentication bug?
Re: [HACKERS] User authentication bug? |
List | 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.Boekhold@et.tudelft.nl | -----------------------------------------------------------------------------
pgsql-hackers by date: