Re: [PATCH] DefaultACLs - Mailing list pgsql-hackers

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)