Tom, > Hmm ... interesting proposal. Simple to understand and simple to > implement, which are both to the good. I'm not clear though on whether > this behavior would be useful in practice. Any comments from those > who've been asking for default ACLs?
I'd be fine with it. My goals here are to make my life easier by eliminating the need for complex GRANT scripts in the simplest cases, and (more importantly) to get web developers to use database object permissions *at all* by making them easy to manage. Robert's suggestion fulfills this. Again, for people who have complex or high security cases, you'd still need a script. That's fine; object permissions are an NP-complete problem anyway, and no feature we adopt is going to cover everyone. But right now we have an issue that probably 98% of Postgres users don't use object permissions *at all* because they're "too difficult to manage". If I had a dollar for every person I saw running Postgres in production as the "postgres" user, or with full public permissions on everything, I could shut down PGX and go back to pottery. > One potential trouble spot is that presumably the built-in default > privileges (eg, PUBLIC EXECUTE for functions) would *not* cumulate > with user-specified defaults. So you'd have a behavior where a > function would not get PUBLIC EXECUTE automatically if it matched > any of the available defaults, but would get it if it managed to > miss matching them all. I am not sure if that's bad or not, but > it seems kind of inconsistent. Yeah, but the fact that functions have PUBLIC EXECUTE by default is inconsistent. All DefaultACLs would be doing is inheriting this inconsistency. Again, I'm OK with that. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
