Re: patch for type privileges
Peter Eisentraut <peter_e@gmx.net>
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-11-15T20:50:18Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Support range data types.
- 4429f6a9e3e1 9.2.0 cited
Attachments
- typacl.patch (text/x-patch) patch
Patch attached. On tis, 2011-11-15 at 22:23 +0200, Peter Eisentraut wrote: > Here is the patch to implement type privileges that I alluded to > earlier. To recall, this is mainly so that owners can prevent others > from using their types because that would in some cases prevent owners > from changing the types. That would effectively be a denial of service. > > These are the interfaces that this patch implements: > > - GRANT USAGE ON DOMAIN > - GRANT USAGE ON TYPE > - default privileges for types > - analogous REVOKEs > - display privileges in psql \dT+ > - privilege checks in various DDL commands (CREATE FUNCTION, CREATE > TABLE, etc.) > - various information schema views adjusted > - has_type_privilege function family > > The basics here are mainly informed by the SQL standard. One thing from > there I did not implement is checking for permission of a type used in > CAST (foo AS type). This would be doable but relatively complicated, > and in practice someone how is not supposed to be able to use the type > wouldn't be able to create the cast or the underlying cast function > anyway for lack of access to the type. > > As elsewhere in the system, the usage of TYPE and DOMAIN is partially > overlapping and partially not. You can use GRANT ON TYPE on a domain > but not GRANT ON DOMAIN on a type (compare CREATE/DROP). We only > support one common set of default privileges for types and domains. I > feel that's enough, but it could be adjusted. > > Open items: > > - GRANT TO ALL TYPES -- haven't gotten to that yet, but could be added > > A reviewer should of course particularly check if there are any holes in > the privilege protection that this patch purports to afford.