Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Tom Lane (t...@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.
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
signature.asc
Description: PGP signature
