Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.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.
regards, tom lane
