Re: patch for type privileges - Mailing list pgsql-hackers
From | Peter Eisentraut |
---|---|
Subject | Re: patch for type privileges |
Date | |
Msg-id | 1323631299.24785.6.camel@vanquo.pezone.net Whole thread Raw |
In response to | Re: patch for type privileges (Yeb Havinga <yebhavinga@gmail.com>) |
Responses |
Re: patch for type privileges
|
List | pgsql-hackers |
On lör, 2011-12-10 at 16:16 +0100, Yeb Havinga wrote: > * ExecGrant_type() prevents 'grant usage on domain' on a type, but the > converse is possible. > > postgres=# create domain myint as int2; > CREATE DOMAIN > postgres=# grant usage on type myint to public; > GRANT This is the same as how we handle types vs. domains elsewhere. For example, you can use DROP TYPE to drop a domain, but you can't use DROP DOMAIN to drop a type. > * Cannot restrict access to array types. After revoking usage from the > element type, the error is perhaps a bit misleading. (smallint[] vs > smallint) > > postgres=> create table a (a int2[]); > ERROR: permission denied for type smallint[] OK, that error message should be improved. > * The patch adds the following text explaining the USAGE privilege on types. > > For types and domains, this privilege allow the use of the type or > domain in the definition of tables, functions, and other schema objects. > > Since other paragraphs in USAGE use the word 'creation' instead of > 'definition', I believe here the word 'creation' should be used too. > IMHO it would also be good to describe what the USAGE privilege is not, > but might be expected since it is such a generic term. USAGE on type: > use of the type while creating new dependencies to the type, not usage > in the sense of instantiating values of the type. If there are existing > dependencies, revoking usage privileges will not return any warning and > the dependencies still exist. Also other kinds of exceptions could be > noted, such as the exception for array types and casts. The example you > gave in the top mail about why restricting access to types can be > useful, such as preventing that owners are prevented changing their > types because others have 'blocked' them by their usage, is something > that could also help readers of the documentation understand why > privileges on types are useful for them (or not). Good suggestions. I'll review the text. > * The information schema view 'attributes' has this additional condition: > AND (pg_has_role(t.typowner, 'USAGE') > OR has_type_privilege(t.oid, 'USAGE')); > > What happens is that attributes in a composite type are shown, or not, > if the current user has USAGE rights. The strange thing here, is that > the attribute in the type being show or not, doesn't match being able to > use it (in the creation of e.g. a table). Yeah, that's a bug. That should be something like AND (pg_has_role(c.relowner, 'USAGE') OR has_type_privilege(c.reltype, 'USAGE')); I'll produce a new patch for these issues in a bit.
pgsql-hackers by date: