Re: Proposal: Save user's original authenticated identity for logging
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Stark <stark@mit.edu>, Jacob Champion <pchampion@vmware.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-02-01T17:43:59Z
Lists: pgsql-hackers
Greetings, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > 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. 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
Commits
-
Add missing $Test::Builder::Level settings
- 73aa5e0cafd0 15.0 landed
- e536a2683439 14.0 landed
-
Add some information about authenticated identity via log_connections
- 9afffcb833d3 14.0 landed
-
Fix some issues with SSL and Kerberos tests
- 5a71964a832f 14.0 landed
-
Refactor all TAP test suites doing connection checks
- c50624cdd248 14.0 landed