Re: Cache invalidation after authentication (on-the-fly role creation)

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cache invalidation after authentication (on-the-fly role creation)
Date: 2018-07-13 04:23:02
Message-ID: CAEepm=1wL5t3T0CeeM3Vuf2K2DKo9UwQOgHrAUiPNzovvYXckQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 13, 2018 at 6:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
>> I suppose the call to AcceptInvalidationMessages() could go at the end
>> of ClientAuthentication(). That'd be closer to the code that creates
>> the negative entry and immediately after the code that might modify
>> the catalogs. Or in PeformAuthentication(), its caller. Or in
>> IntializeSessionUserId() immediately before we try to look up the
>> name, but that's also called by background workers that don't need it.
>
> I think my preference would be to put it in InitializeSessionUserId
> so that it's clearly associated with the syscache lookups we're trying
> to protect.

Thanks. Pushed to master that way.

With this change, I can successfully use a little PAM module that
authenticates with an LDAP server and then creates, grants and revokes
roles as necessary based on LDAP groups. It's not as good as
Stephen's grand plan, but it's dead simple. Without the change, it
still works, but the first login attempt for a given user fails. I
can live with that in the back branches.

> I don't entirely buy your argument that background workers
> don't need up-to-date info for this.

Yeah, a hypothetical background worker that starts up and then waits
to be told the name of the role to use could suffer from this problem.

--
Thomas Munro
http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-07-13 04:29:57 Re: Temporary tables prevent autovacuum, leading to XID wraparound
Previous Message Kato, Sho 2018-07-13 03:53:26 RE: How to make partitioning scale better for larger numbers of partitions