Re: Proposal: Save user's original authenticated identity for logging
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Greg Stark <stark@mit.edu>, Jacob Champion <pchampion@vmware.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-02-01T17:32:09Z
Lists: pgsql-hackers
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
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