Re: Record last password change

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Banck <michael(dot)banck(at)credativ(dot)de>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Record last password change
Date: 2019-01-05 22:40:10
Message-ID: 20190105224010.GY2528@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > ... Definitely a +1 from me, but I'd like us to be thinking about the other
> > things we should be doing in this area to bring our password-based
> > authentication mechanism kicking-and-screaming into the current decade.
>
> I'm not really excited about reinventing the whole of PAM, which is
> where this argument seems to be leading.

PAM isn't supported on all of our platforms and, really, even where we
do support it, it's frankly beyond impractical to actually use the PAM
modules because they expect to be run as root, which we don't do.

I can understand that you're not excited about it, and I'm not keen to
reinvent all of PAM (there's an awful lot of it which we really don't
need), but there are features that happen to also exist in PAM (and
Kerberos, and LDAP, and RADIUS, and...) that we really should have in
our own password-based authentication system because our users are
expecting them. Looking at the various forks of PG that are out there
shows that quite clearly, I don't imagine they implemented these
features out of pure fun, and they obviously also realized that trying
to actually use PAM from PG was ultimately a bad idea.

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2019-01-05 23:34:14 Re: Facility for detecting insecure object naming
Previous Message Stephen Frost 2019-01-05 22:12:14 Re: Offline enabling/disabling of data checksums