Re: Proposal: Save user's original authenticated identity for logging

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <stark(at)mit(dot)edu>, Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Save user's original authenticated identity for logging
Date: 2021-02-01 17:43:59
Message-ID: 20210201174359.GK27507@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:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> >> This doesn't sound particularly workable: how would you manage
> >> inside-the-database permissions? Kerberos isn't going to know
> >> what "view foo" is, let alone know whether you should be allowed
> >> to read or write it. So ISTM there has to be a role to hold
> >> those permissions. Certainly, you could allow multiple external
> >> identities to share a role ... but that works today.
>
> > Agreed- we would need something in the database to tie it to and I don't
> > see it making much sense to try to invent something else for that when
> > that's what roles are. What's been discussed before and would certainly
> > be nice, however, would be a way to have roles automatically created.
> > There's pg_ldap_sync for that today but it'd be nice to have something
> > built-in and which happens at connection/authentication time, or maybe a
> > background worker that connects to an ldap server and listens for
> > changes and creates appropriate roles when they're created. Considering
> > we've got the LDAP code already, that'd be a really nice capability.
>
> That's still got the same issue though: where does the role get any
> permissions from?
>
> I suppose you could say "allow auto-creation of new roles and make them
> members of group X", where X holds the permissions that "everybody"
> should have. But I'm not sure how much that buys compared to just
> letting everyone log in as X.

Right, pg_ldap_sync already supports making new roles a member of
another role in PG such as a group role, we'd want to do something
similar. Also- once the role exists, then permissions could be assigned
directly as well, of course, which would be the advantage of a
background worker that's keeping the set of roles in sync, as the role
would be created at nearly the same time in both the authentication
system itself (eg: AD) and in PG. That kind of integration exists in
other products and would go a long way to making PG easier to use and
administer.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2021-02-01 17:44:18 Re: Proposal: Save user's original authenticated identity for logging
Previous Message John Naylor 2021-02-01 17:32:23 [POC] verifying UTF-8 using SIMD instructions