"Paul Hart" <paulhart@io.com> writes:
> However, based on that, I would guess that the crypt() problem isn't it.
> As for the postmaster log file, there is nothing special in there:
> verify_password: password mismatch for 'XXXX'.
No, that tells us quite a lot: checking in the source code for that
message, I can see that the backend has received your username and
password, and has found the username in an external password file,
and has attempted to match your password against what was in the
password file. And that match didn't work. I think that crypt()
is exactly where your problem is. Did you build the external
password file with pg_passwd, or manually?
> Uhm... would that then mean that if I was on an OpenBSD machine as a
> client (i.e. just running psql), I would be unable (at least without
> massaging some code) to access a postgres instance on, say, a Solaris
> box? That sounds *very* fishy to me.
If you use the crypt auth method (crypt on client side and send
that across the wire) then yes, the crypt algorithms offered by
client and server C libraries had better match. However, AFAICT
you are not doing that. In the regular passwd method what we are
assuming is that the crypt library routine linked into the
postmaster is the same one linked into pg_passwd, or whatever
program you use to maintain the flat password file. Since these
are on the same machine it's not such a big assumption.
> Any chance we can have a standardized hashing function built into the
> code?
Are you volunteering? There have been a couple of long discussions
on pghackers about a better password challenge protocol. IIRC we
came up with a good-looking paper design, but there was a notable
lack of effort on actually making it happen.
regards, tom lane
