Tom Lane wrote:
So my feeling is that adding GRANT ON VIEW is a bad idea. The main
argument for doing it seemed to be that the author wanted to be able
to grant different default privileges for tables and views, but I'm
unconvinced that there's a strong use-case for that. You could very
Yes that was the intention. I do have users in my databases with access
privileges to VIEWs but not to underlying TABLEs so it seemed like a
good idea to be able to do that with DefaultACLs and GRANT ON ALL.
Second: both this patch and GRANT ON ALL are built on the assumption
that the only way to filter/classify objects is by schema membership.
Now I don't object to that as an initial implementation restriction,
but I don't like hard-wiring it into the syntax. It is very clear to me
that we'll want other filter rules in the future --- an immediate example
is being able to say that new children of an inheritance parent table
should inherit its GRANTs. So to my mind, designing the syntax around
ALTER SCHEMA is right out. Maybe we could do something like
ALTER DEFAULT PRIVILEGES ON TABLES IN SCHEMA foo GRANT ...
where the "IN SCHEMA foo" part would be subject to generalization later.
This also matches up a bit better with the proposed syntax for GRANT
ON ALL (which also uses "IN SCHEMA foo").
Actually I was planning to extend GRANT ON ALL - if it was accepted - to
include more filters (something like OWNED BY for example).
Third: speaking of syntax, I don't like the way that this is gratituously
different from GRANT/REVOKE. I don't like using ADD/DROP instead of
GRANT/REVOKE, nor the unnecessary AND business. I think we should
minimize confusion by using something that is spelled as nearly like
GRANT/REVOKE as possible.
ADD/DROP was side product of having SET and that "unnecessary AND business".
If we went with that syntax you proposed we could just put exact same
syntax as GRANT and REVOKE after the filtering option, that should be
close enough :). I remember Stephen being against having GRANT in ALTER
SCHEMA but I doubt he would be against having it in completely new ALTER
DEFAULT PRIVILEGES statement.
Fourth: the system's existing treatment of default permissions is
owner-dependent, that is the implied set of permissions is typically
GRANT ALL TO <owner> (from himself, with grant option). I do not
understand how schema-level default ACLs will play nicely with that,
except in the special case where the schema owner also owns every
contained object. If you copy the schema-level ACL directly to a
contained object with a different owner it will definitely be the wrong
thing, but if you try to translate the ownership it will confuse people
too. And confusion in a security-related behavior is a Bad Thing.
Furthermore, having the schema owner able to control the grants made
for objects not owned by him is a huge security hole.
We were actually discussing this with Stephen yesterday as something
similar occurred to me too. The patch as submitted just does the copy,
after the discussion I added post-processing on object creation which
translates everything to owner but I guess there is no point in
submitting that now.
What I suggest as a way to resolve this last point is that a default ACL
should apply only to objects owned by the user who creates/modifies the
default ACL. In this view, the question of which schema the objects are
in is just an additional filter condition, not the primary determinant
of which objects a default ACL applies to. Every user has his own set
of default ACLs.
We could certainly do that. I wonder what we should do about inheritance
of default privileges between the roles if we did this - should it just
be what I set is mine and my parent roles do not affect me or should it
get default privs from parent roles and merge them with mine when I
create the object ? Also when creating new default privileges entry
should we use some template which would give owner all privileges like
GRANT does when there are no existing privileges on object or should we
just use blank and leave it to user to grant himself default privileges
on objects he will create ?
I don't think there is any point in you looking at code since
DefaultACLs might need serious rewriting.
GRANT ON ALL is a bit different story, there I can just remove all that
VIEW stuff, although I would very much like to have the ability to
affect only VIEWs. On the other hand removing VIEW as separate object
type would remove my biggest problem with how both patches are
implemented (I mentioned it few times in the previous discussion) so
from that standpoint it might be a good thing.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
