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
