From pgsql-hackers-owner@postgresql.org Thu Apr 19 15:15:30 2001 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f3JId1301805 for ; Thu, 19 Apr 2001 14:39:02 -0400 (EDT) (envelope-from peter_e@gmx.net) Received: from fwd03.sul.t-online.com by mailout02.sul.t-online.com with smtp id 14qGe9-0005Ng-05; Thu, 19 Apr 2001 17:47:05 +0200 Received: from peter.localdomain (520083510237-0001@[217.80.146.53]) by fmrl03.sul.t-online.com with esmtp id 14qGe4-2H8UKWC; Thu, 19 Apr 2001 17:47:00 +0200 Date: Thu, 19 Apr 2001 17:58:12 +0200 (CEST) From: Peter Eisentraut To: PostgreSQL Development Subject: System catalog representation of access privileges Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: 520083510237-0001@t-dialin.net X-Archive-Number: 200104/704 X-Sequence-Number: 7734 Status: OR Oldtimers might recall the last thread about enhancements of the access privilege system. See http://www.postgresql.org/mhonarc/pgsql-hackers/2000-05/msg01220.html to catch up. It was more or less agreed that privilege descriptors should be split out into a separate table for better flexibility and ease of processing. The dispute was that the old proposal wanted to store only one privilege per row. I have devised something more efficient: pg_privilege ( priobj oid, -- oid of table, column, function, etc. prigrantor oid, -- user who granted the privilege prigrantee oid, -- user who owns the privilege priselect char, -- specific privileges follow... prihierarchy char, priinsert char, priupdate char, pridelete char, prireferences char, priunder char, pritrigger char, prirule char /* obvious extension mechanism... */ ) The various "char" fields would be NULL for not granted, some character for granted, and some other character for granted with grant option (a poor man's enum, if you will). Votes on the particular characters are being taken. ;-) Since NULLs are stored specially, sparse pg_privilege rows wouldn't take extra space. "Usage" privileges on types and other non-table objects could probably be lumped under "priselect" (purely for internal purposes). For access we define system caches on these indexes: index ( priobj, prigrantee, priselect ) index ( priobj, prigrantee, prihierarchy ) index ( priobj, prigrantee, priinsert ) index ( priobj, prigrantee, priupdate ) index ( priobj, prigrantee, pridelete ) These are the privileges you usually need quickly during query processing, the others are only needed during table creation. These indexes are not unique (more than one grantor can grant the same privilege), but AFAICS the syscache interface should work okay with this, since in normal operation we don't care who granted the privilege, only whether you have at least one. How does that look? -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter From pgsql-hackers-owner+M7738@postgresql.org Thu Apr 19 16:28:19 2001 Return-path: Received: from postgresql.org (webmail.postgresql.org [216.126.85.28]) by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f3JKSJL13468 for ; Thu, 19 Apr 2001 16:28:19 -0400 (EDT) Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) by postgresql.org (8.11.3/8.11.1) with SMTP id f3JKRH336850; Thu, 19 Apr 2001 16:27:17 -0400 (EDT) (envelope-from pgsql-hackers-owner+M7738@postgresql.org) Received: from wallace.ece.rice.edu (wallace.ece.rice.edu [128.42.12.154]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f3JJbq325185 for ; Thu, 19 Apr 2001 15:37:52 -0400 (EDT) (envelope-from reedstrm@rice.edu) Received: by rice.edu via sendmail from stdin id (Debian Smail3.2.0.102) for pgsql-hackers@postgresql.org; Thu, 19 Apr 2001 14:37:48 -0500 (CDT) Date: Thu, 19 Apr 2001 14:37:48 -0500 From: "Ross J. Reedstrom" To: Peter Eisentraut cc: PostgreSQL Development Subject: Re: [HACKERS] System catalog representation of access privileges Message-ID: <20010419143748.A3815@rice.edu> Mail-Followup-To: Peter Eisentraut , PostgreSQL Development References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i In-Reply-To: ; from peter_e@gmx.net on Thu, Apr 19, 2001 at 05:58:12PM +0200 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR So, this will remove the relacl field from pg_class, making pg_class a fixed tuple-length table: that might actually speed access: there are shortcircuits in place to speed pointer math when this is true. The implementation looks fine to me, as well. How are group privileges going to be handled with this system? Ross On Thu, Apr 19, 2001 at 05:58:12PM +0200, Peter Eisentraut wrote: > Oldtimers might recall the last thread about enhancements of the access > privilege system. See > > http://www.postgresql.org/mhonarc/pgsql-hackers/2000-05/msg01220.html > > to catch up. > > It was more or less agreed that privilege descriptors should be split out > into a separate table for better flexibility and ease of processing. The > dispute was that the old proposal wanted to store only one privilege per > row. I have devised something more efficient: > > pg_privilege ( ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl From pgsql-hackers-owner+M7737@postgresql.org Thu Apr 19 16:22:45 2001 Return-path: Received: from postgresql.org (webmail.postgresql.org [216.126.85.28]) by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f3JKMiL12982 for ; Thu, 19 Apr 2001 16:22:45 -0400 (EDT) Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) by postgresql.org (8.11.3/8.11.1) with SMTP id f3JKME335538; Thu, 19 Apr 2001 16:22:14 -0400 (EDT) (envelope-from pgsql-hackers-owner+M7737@postgresql.org) Received: from corvette.mascari.com (dhcp065-024-161-045.columbus.rr.com [65.24.161.45]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f3JKJK334679 for ; Thu, 19 Apr 2001 16:19:20 -0400 (EDT) (envelope-from mascarm@mascari.com) Received: from mascari.com (ferrari.mascari.com [192.168.2.1]) by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id QAA25251; Thu, 19 Apr 2001 16:12:11 -0400 Message-ID: <3ADF47F0.82BD3A63@mascari.com> Date: Thu, 19 Apr 2001 16:17:52 -0400 From: Mike Mascari Organization: Mascari Development Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Peter Eisentraut cc: PostgreSQL Development Subject: Re: [HACKERS] System catalog representation of access privileges References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Peter Eisentraut wrote: > I have devised something more efficient: > > pg_privilege ( > priobj oid, -- oid of table, column, etc. > prigrantor oid, -- user who granted the privilege > prigrantee oid, -- user who owns the privilege > > priselect char, -- specific privileges follow... > prihierarchy char, > priinsert char, > priupdate char, > pridelete char, > prireferences char, > priunder char, > pritrigger char, > prirule char > /* obvious extension mechanism... */ > ) > > "Usage" privileges on types and other non-table objects could probably be > lumped under "priselect" (purely for internal purposes). > That looks quite nice. I do have 3 quick questions though. First, I assume that the prigrantee could also be a group id? Or would this system table represent the effective privileges granted to user via groups? Second, one nice feature of Oracle is the ability to GRANT roles (our groups) to other roles. So I could do: CREATE ROLE clerk; GRANT SELECT on mascarm.deposits TO clerk; GRANT UPDATE (mascarm.deposits.amount) ON mascarm.deposits TO clerk; CREATE ROLE banker; GRANT clerk TO banker; Would any part of your design prohibit such functionality in the future? Finally, I'm wondering if "Usage" or "System" privileges should be another system table. For example, one day I would like to (as in Oracle): GRANT SELECT ANY TABLE TO foo WITH ADMIN; GRANT CREATE PUBLIC SYNONYM TO foo; GRANT DROP ANY TABLE TO foo; Presumably, in your design, the above would be represented by 3 records with something like the following values: This would be a "SELECT ANY TABLE" privilege (w/Admin): NULL, grantor_oid, grantee_oid, 'S', NULL, NULL, NULL, NULL, ... This would be a "CREATE PUBLIC SYNONYM" privilege: NULL, grantor_oid, grantee_oid, 'c', NULL, NULL, NULL, NULL, ... That means that the system would need an index as: index ( prigrantee, priselect ) While I'm not arguing it won't work, it just doesn't "seem" clean to shoe-horn the system privileges into the same table as the object privileges. I've been wrong before though :-) Mike Mascari mascarm@mascari.com ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl From pgsql-hackers-owner+M7740@postgresql.org Thu Apr 19 17:17:08 2001 Return-path: Received: from postgresql.org (webmail.postgresql.org [216.126.85.28]) by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f3JLH6L23163 for ; Thu, 19 Apr 2001 17:17:07 -0400 (EDT) Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) by postgresql.org (8.11.3/8.11.1) with SMTP id f3JLGL348132; Thu, 19 Apr 2001 17:16:21 -0400 (EDT) (envelope-from pgsql-hackers-owner+M7740@postgresql.org) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f3JLDx347396 for ; Thu, 19 Apr 2001 17:13:59 -0400 (EDT) (envelope-from peter_e@gmx.net) Received: from fwd03.sul.t-online.com by mailout04.sul.t-online.com with smtp id 14qLkP-0001K0-04; Thu, 19 Apr 2001 23:13:53 +0200 Received: from peter.localdomain (520083510237-0001@[217.80.146.53]) by fmrl03.sul.t-online.com with esmtp id 14qLk8-0Y7RFAC; Thu, 19 Apr 2001 23:13:36 +0200 Date: Thu, 19 Apr 2001 23:24:51 +0200 (CEST) From: Peter Eisentraut To: Mike Mascari cc: PostgreSQL Development Subject: Re: [HACKERS] System catalog representation of access privileges In-Reply-To: <3ADF47F0.82BD3A63@mascari.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: 520083510237-0001@t-dialin.net Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Mike Mascari writes: > That looks quite nice. I do have 3 quick questions though. First, I > assume that the prigrantee could also be a group id? Yes. It was also suggested making two different grantee columns for users and groups, but I'm not yet convinced of that. It's an option though. > Second, one nice feature of Oracle is the ability to GRANT roles > (our groups) to other roles. Roles are not part of this deal, although I agree that they would be nice to have eventually. I'm not sure yet whether role grants would get a different system table, but I'm leaning there. > Would any part of your design prohibit such functionality in the future? Not that I can see. > Finally, I'm wondering if "Usage" or "System" privileges should be > another system table. For example, one day I would like to (as in > Oracle): > > GRANT SELECT ANY TABLE TO foo WITH ADMIN; ANY TABLE probably implies "any table in this schema/database", no? In that case the grant record would refer to the oid of the schema/database. Is there any use distinguishing between ANY TABLE and ANY VIEW? That would make it a bit trickier. > GRANT CREATE PUBLIC SYNONYM TO foo; I'm not familiar with that above command. > GRANT DROP ANY TABLE TO foo; I'm not sold on a DROP privilege, but a CREATE privilege would be another column. I didn't include it here because it's not in SQL. > While I'm not arguing it won't work, it just doesn't "seem" clean to > shoe-horn the system privileges into the same table as the object > privileges. It would make sense to split privileges on tables from privileges on schemas/databases from privileges on, say, functions, etc. E.g., pg_privtable -- like proposed pg_privschema ( priobj oid, prigrantor oid, prigrantee oid, char pritarget, -- 't' = any table, 'v' = any view, ... char priselect, char priupdate, /* etc */ ) But this would mean that a check like "can I select from this table" would possibly require lookups in two tables. Not sure how much of a tradeoff that is, but the "shoehorn factor" would be lower. Comments on this? -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly From pgsql-hackers-owner+M7741@postgresql.org Thu Apr 19 18:12:56 2001 Return-path: Received: from postgresql.org (webmail.postgresql.org [216.126.85.28]) by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f3JMCtL28468 for ; Thu, 19 Apr 2001 18:12:55 -0400 (EDT) Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) by postgresql.org (8.11.3/8.11.1) with SMTP id f3JMCF359250; Thu, 19 Apr 2001 18:12:15 -0400 (EDT) (envelope-from pgsql-hackers-owner+M7741@postgresql.org) Received: from sss.pgh.pa.us ([216.151.103.158]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f3JLrW355044 for ; Thu, 19 Apr 2001 17:53:32 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.3/8.11.3) with ESMTP id f3JLrQR22762; Thu, 19 Apr 2001 17:53:26 -0400 (EDT) To: Peter Eisentraut cc: PostgreSQL Development Subject: Re: [HACKERS] System catalog representation of access privileges In-Reply-To: References: Comments: In-reply-to Peter Eisentraut message dated "Thu, 19 Apr 2001 17:58:12 +0200" Date: Thu, 19 Apr 2001 17:53:26 -0400 Message-ID: <22759.987717206@sss.pgh.pa.us> From: Tom Lane Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Peter Eisentraut writes: > pg_privilege ( > priobj oid, -- oid of table, column, function, etc. > prigrantor oid, -- user who granted the privilege > prigrantee oid, -- user who owns the privilege What about groups? What about wildcards? We already allow "grant to PUBLIC (all)", and it would be nice to be able to do something like "grant to joeblow" > Since NULLs are stored specially, sparse pg_privilege > rows wouldn't take extra space. Unless there get to be a very large number of privilege bits, it'd probably be better to handle these columns as NOT NULL, so that a fixed C struct record could be mapped onto the tuples. You'll notice that most of the other system tables are done that way. Alternatively, since you really only need two bits per privilege, perhaps a pair of BIT (VARYING?) fields would be a more effective approach. BIT VARYING would have the nice property that adding a new privilege type doesn't force initdb. > For access we define system caches on these indexes: > index ( priobj, prigrantee, priselect ) > index ( priobj, prigrantee, prihierarchy ) > index ( priobj, prigrantee, priinsert ) > index ( priobj, prigrantee, priupdate ) > index ( priobj, prigrantee, pridelete ) Using the privilege bits as part of the index won't work if you intend to allow them to be null. Another objection is that this would end up caching multiple copies of the same tuple. A third is that you can't readily tell lack of an entry (implying you should use a default ACL setting, which might allow the access) from presence of an entry denying the access. A fourth is it doesn't work for groups or wildcards. > These indexes are not > unique (more than one grantor can grant the same privilege), but AFAICS > the syscache interface should work okay with this, Unfortunately not. The syscache stuff needs unique indexes, because it can only return one tuple for any given request. I don't really believe this indexing scheme is workable. Need to think some more. Possibly the syscache mechanism will not do, and we need a specially indexed privilege cache instead. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly From pgsql-hackers-owner+M7743@postgresql.org Thu Apr 19 18:47:11 2001 Return-path: Received: from postgresql.org (webmail.postgresql.org [216.126.85.28]) by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f3JMlAL29690 for ; Thu, 19 Apr 2001 18:47:10 -0400 (EDT) Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) by postgresql.org (8.11.3/8.11.1) with SMTP id f3JMkg366031; Thu, 19 Apr 2001 18:46:42 -0400 (EDT) (envelope-from pgsql-hackers-owner+M7743@postgresql.org) Received: from corvette.mascari.com (dhcp065-024-161-045.columbus.rr.com [65.24.161.45]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f3JMZf364328 for ; Thu, 19 Apr 2001 18:35:41 -0400 (EDT) (envelope-from mascarm@mascari.com) Received: from mascari.com (ferrari.mascari.com [192.168.2.1]) by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id SAA25665; Thu, 19 Apr 2001 18:28:30 -0400 Message-ID: <3ADF67E3.8367B467@mascari.com> Date: Thu, 19 Apr 2001 18:34:11 -0400 From: Mike Mascari Organization: Mascari Development Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Peter Eisentraut cc: PostgreSQL Development Subject: Re: [HACKERS] System catalog representation of access privileges References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR First, let me say that just because Oracle does it this way doesn't make it better but... Oracle divides privileges into 2 categories: Object privileges System privileges The Object privileges are the ones you describe. And I agree fundamentally with your design. Although I would have (a) used a bitmask for the privileges and (b) have an additional bitmask which determines whether or not the Grantee could turn around and grant the same permission to someone else: pg_objprivs { priobj oid, prigrantor oid, prigrantee oid, priprivileges int4, priadmin int4 }; Where priprivileges is a bitmask for: 0 ALTER - tables, sequences 1 DELETE - tables, views 2 EXECUTE - procedures, functions 3 INDEX - tables 4 INSERT - tables, views 5 REFERENCES - tables 6 SELECT - tables, views, sequences 7 UPDATE - tables, views 8 HIERARCHY - tables 9 UNDER - tables And the priadmin is a bitmask to determine whether or not the Grantee could grant the same privilege to another user. Since these are Object privileges, 32 bits should be enough (and also 640K RAM ;-)). The System privileges are privileges granted to a user or role (a.k.a group) which are not associated with any particular object. This is one area where I think PostgreSQL needs a lot of work and thought, particularly with schemas coming down the road. Some example Oracle System privileges are: Typical User Privileges: ----------------------- CREATE SESSION - Allows the user to connect CREATE SEQUENCE - Allows the user to create sequences in his schema CREATE SYNONYM - Allows the user to create private synonyms CREATE TABLE - Allows the user to create a table in his schema CREATE TRIGGER - Allows the user to create triggers on tables in his schema CREATE VIEW - Allows the user to create views in his schema Typical Power-User Privileges: ----------------------------- ALTER ANY INDEX - Allows user to alter an index in *any* schema ALTER ANY PROCEDURE - Allows user to alter a procedure in *any* schema ALTER ANY TABLE - Allows user to alter a table in *any* schema ... CREATE ANY TABLE - Allows user to create a table in *any* schema COMMENT ANY TABLE - Allows user to document any table in *any* schema ... Typical DBA-Only Privileges: --------------------------- ALTER USER - Allows user to change password, quotas, etc. for *any* user CREATE USER - Allows user to create a new user DROP USER - Allows user to drop a new user GRANT ANY PRIVILEGE - Allows user to grant any privilege to any user ANALYZE ANY - Allows user to analyze any table in *any* schema There are, in fact, many, many more System Privileges that Oracle defines. You may want someone to connect to a database and query one table and that's it. Or you may want someone to have no other abilities except to document the database design via the great COMMENT ON command ;-), etc. So for System Privileges, I would have something like: pg_sysprivs { prigrantee oid, priprivilege oid, prigroup bool, priadmin bool }; So each System privilege granted to a user (or group) would be its own record. The priprivilege would be the OID of one of the many System privileges defined in the same way types are defined, if prigroup is false. If prigroup is true, however, then priprivilege is not a System privilege, but a group id. And then PostgreSQL will have to examine the privileges recursively for that group. Of course, you might not want to allow for the GRANTing of group privileges to other groups initially, which simplifies the implementation tremendously. But its a neat (if not complicated) Oracle-ism. Unfortunately, this means that the permission might require > 2 lookups. But these lookups are only if the previous lookup failed: SELECT * FROM employees.foo; 1. Am I a member of the employees schema? Yes -> Done 2. Have I been GRANTed the Object Privilege of: SELECT on employees.foo? Yes -> Done 3. Have I been GRANTed the System Privilege of: SELECT ANY TABLE? Yes -> Done So the number of lookups does potentially increase, but only for those users that have been granted access through greater and greater layers of authority. I just think that each new feature added to PostgreSQL opens up a very large can of worms. Schemas are such a feature and the security system should be prepared for it. FWIW, Mike Mascari mascarm@mascari.com Peter Eisentraut wrote: > > > It would make sense to split privileges on tables from privileges on > schemas/databases from privileges on, say, functions, etc. E.g., > > pg_privtable -- like proposed > > pg_privschema ( > priobj oid, prigrantor oid, prigrantee oid, > char pritarget, -- 't' = any table, 'v' = any view, ... > char priselect, > char priupdate, > /* etc */ > ) > > But this would mean that a check like "can I select from this table" > would possibly require lookups in two tables. Not sure how much of a > tradeoff that is, but the "shoehorn factor" would be lower. > > Comments on this? > > -- > Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) From pgsql-hackers-owner+M7759@postgresql.org Fri Apr 20 11:25:24 2001 Return-path: Received: from postgresql.org (webmail.postgresql.org [216.126.85.28]) by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f3KFPNs14733 for ; Fri, 20 Apr 2001 11:25:23 -0400 (EDT) Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) by postgresql.org (8.11.3/8.11.1) with SMTP id f3KFNa389638; Fri, 20 Apr 2001 11:23:36 -0400 (EDT) (envelope-from pgsql-hackers-owner+M7759@postgresql.org) Received: from mailout00.sul.t-online.com (mailout00.sul.t-online.com [194.25.134.16]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f3KFLL388804 for ; Fri, 20 Apr 2001 11:21:21 -0400 (EDT) (envelope-from peter_e@gmx.net) Received: from fwd04.sul.t-online.com by mailout00.sul.t-online.com with smtp id 14qchk-0001xH-01; Fri, 20 Apr 2001 17:20:16 +0200 Received: from peter.localdomain (520083510237-0001@[212.185.245.11]) by fmrl04.sul.t-online.com with esmtp id 14qchV-2L4flAC; Fri, 20 Apr 2001 17:20:01 +0200 Date: Fri, 20 Apr 2001 17:31:16 +0200 (CEST) From: Peter Eisentraut To: Tom Lane cc: PostgreSQL Development Subject: Re: [HACKERS] System catalog representation of access privileges In-Reply-To: <22759.987717206@sss.pgh.pa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: 520083510237-0001@t-dialin.net Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Tom Lane writes: > Peter Eisentraut writes: > > pg_privilege ( > > priobj oid, -- oid of table, column, function, etc. > > prigrantor oid, -- user who granted the privilege > > prigrantee oid, -- user who owns the privilege > > What about groups? Either integrated into prigrantee or another column prigroupgrantee. One of these would always be zero or null, that's why I'm not sure if this isn't a waste of space. > What about wildcards? We already allow > "grant to PUBLIC (all)", and it would be nice to be able to do > something like "grant to joeblow" Public would be prigrantee == 0. About , how is this defined? If it is "everything I own and will ever own" then I suppose priobj == 0. Although I admit I have never seen this kind of privilege before. It's probably better to set up a group for that. > Alternatively, since you really only need two bits per privilege, > perhaps a pair of BIT (VARYING?) fields would be a more effective > approach. BIT VARYING would have the nice property that adding a new > privilege type doesn't force initdb. This would be tricky to index, I think. > I don't really believe this indexing scheme is workable. Need to think > some more. Possibly the syscache mechanism will not do, and we need a > specially indexed privilege cache instead. Maybe just an index on (object, grantee) and walk through that with an index scan. This is done in some other places as well (triggers, I recall), but the performance is probably not too exciting. However, last I looked at the syscache I figured that it would be perfectly capable of handling non-unique indexes if there only was an API to retrieve those values. Storing and finding the entries didn't seem to be the problem. Need to look there, probably. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org From pgsql-hackers-owner+M7763@postgresql.org Fri Apr 20 13:05:45 2001 Return-path: Received: from west.navpoint.com (root@west.navpoint.com [207.106.42.13]) by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f3KH5jE01810 for ; Fri, 20 Apr 2001 13:05:45 -0400 (EDT) Received: from postgresql.org (webmail.postgresql.org [216.126.85.28]) by west.navpoint.com (8.11.3/8.10.1) with ESMTP id f3KGc8129062 for ; Fri, 20 Apr 2001 12:38:08 -0400 (EDT) Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) by postgresql.org (8.11.3/8.11.1) with SMTP id f3KGbY311283; Fri, 20 Apr 2001 12:37:34 -0400 (EDT) (envelope-from pgsql-hackers-owner+M7763@postgresql.org) Received: from sss.pgh.pa.us ([216.151.103.158]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f3KGZp310688 for ; Fri, 20 Apr 2001 12:35:51 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.3/8.11.3) with ESMTP id f3KGZlR26837; Fri, 20 Apr 2001 12:35:47 -0400 (EDT) To: Peter Eisentraut cc: PostgreSQL Development Subject: Re: [HACKERS] System catalog representation of access privileges In-Reply-To: References: Comments: In-reply-to Peter Eisentraut message dated "Fri, 20 Apr 2001 17:31:16 +0200" Date: Fri, 20 Apr 2001 12:35:46 -0400 Message-ID: <26834.987784546@sss.pgh.pa.us> From: Tom Lane Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Peter Eisentraut writes: >> Alternatively, since you really only need two bits per privilege, >> perhaps a pair of BIT (VARYING?) fields would be a more effective >> approach. BIT VARYING would have the nice property that adding a new >> privilege type doesn't force initdb. > This would be tricky to index, I think. True, but I don't believe that making the privilege value part of the index is useful. > Maybe just an index on (object, grantee) and walk through that with an > index scan. This is done in some other places as well (triggers, I > recall), but the performance is probably not too exciting. I agree, that'd be slower than we'd like. It needs to be cached somehow. The major problem is that you'd need multiple index scans: after failing to find anything for (table, currentuser) you'd also need to try (table, 0) for PUBLIC and (table, G) for every group G that contains the current user. Not to mention the scan to find out which groups those are. It gets rapidly worse if you want to allow any wildcarding on the object --- for example, if a privilege record attached to a schema can allow access to the tables therein, which I think should be possible. You'd have to repeat the above for each possible priobject that might relate to the target object. I think this might be tolerable for getting the info in the first place, but the final results really need to be cached. That's why I was wondering about a special "privilege cache". > However, last I looked at the syscache I figured that it would be > perfectly capable of handling non-unique indexes if there only was an API > to retrieve those values. Yes, it's an API problem more than anything else. Invent away, if that seems like a needed component. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html From pgsql-hackers-owner+M4091@postgresql.org Mon Jan 29 17:00:26 2001 Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28]) by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA13925 for ; Mon, 29 Jan 2001 18:00:25 -0500 (EST) Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28]) by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f0TMq7q43267; Mon, 29 Jan 2001 17:52:07 -0500 (EST) (envelope-from pgsql-hackers-owner+M4091@postgresql.org) Received: from ara.zf.jcu.cz (ara.zf.jcu.cz [160.217.161.4]) by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f0TMbYq42245 for ; Mon, 29 Jan 2001 17:37:34 -0500 (EST) (envelope-from zakkr@zf.jcu.cz) Received: from localhost (zakkr@localhost) by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id XAA32063; Mon, 29 Jan 2001 23:37:08 +0100 Date: Mon, 29 Jan 2001 23:37:08 +0100 (CET) From: Karel Zak To: =?koi8-r?B?7cHL08nNIO0uIPDPzNHLz9c=?= cc: pgsql-hackers Subject: [HACKERS] NOCREATETABLE patch (was: Re: Please, help!(about Postgres)) In-Reply-To: <005d01c08772$de689030$1e01a8c0@bresttelecom> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.postgresql.org id f0TMbYq42246 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: ORr On Fri, 26 Jan 2001, [koi8-r] Максим М. Поляков wrote: > Good Day, Dear Karel Zak! > > Please, forgive me for my bad english and if i do not right with your > day time. my English is more poor :-) You are right, it is (was?) in TODO and it will implemented - I hope - in some next release (may be in 7.2 during ACL overhaul, Peter?). Before some time I wrote patch that resolve it for 7.0.2 (anyone - I forgot his name..) port it to 7.0.2, my original patch was for 7.0.0. May be will possible use it for last stable 7.0.3 too. The patch is at: ftp://ftp2.zf.jcu.cz/users/zakkr/pg/7.0.2-user.patch.gz This patch add to 7.0.2 code NOCREATETABLE and NOLOCKTABLE feature: CREATE USER username [ WITH [ SYSID uid ] [ PASSWORD 'password' ] ] [ CREATEDB | NOCREATEDB ] [ CREATEUSER | NOCREATEUSER ] -> [ CREATETABLE | NOCREATETABLE ] [ LOCKTABLE | NOLOCKTABLE ] ...etc. If CREATETABLE or LOCKTABLE is not specific in CREATE USER command, as default is set CREATETABLE or LOCKTABLE (true). But, don't forget - it's temporarily solution, I hope that some next release resolve it more systematic. More is in the patche@postgresql.org archive where was send original patch. Because you are not first person that ask me, I re-post (CC:) it to hackers@postgresql.org, more admins happy with this :-) Karel > I want to ask You about "access control over who can create tables and > use locks in PostgreSQL". This message was placed in PostgreSQL site > TODO list. But now it was deleted. I so need help about this question, > becouse i'll making a site witch will give hosting for our users. > And i want to make a PostgreSQL access to their own databases. But there > is (how You now) one problem. Anyone user may to connect to the different > user database and he may to create himself tables. > I don't like it. From mascarm@mascari.com Mon May 7 15:57:48 2001 Return-path: Received: from corvette.mascari.com (dhcp065-024-161-045.columbus.rr.com [65.24.161.45]) by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f47Jvku26379 for ; Mon, 7 May 2001 15:57:47 -0400 (EDT) Received: from ferrari (ferrari.mascari.com [192.168.2.1]) by corvette.mascari.com (8.9.3/8.9.3) with SMTP id PAA06587; Mon, 7 May 2001 15:47:59 -0400 Received: by localhost with Microsoft MAPI; Mon, 7 May 2001 15:55:53 -0400 Message-ID: <01C0D70E.3241C920.mascarm@mascari.com> From: Mike Mascari Reply-To: "mascarm@mascari.com" To: "'Bruce Momjian'" , Karel Zak cc: pgsql-hackers Subject: RE: [HACKERS] NOCREATETABLE patch (was: Re: Please, help!(about Postgres)) Date: Mon, 7 May 2001 15:55:52 -0400 Organization: Mascari Development Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: OR Peter E. posted his proposal for the revamping of the authentication/security system a few weeks ago. There was a discussion, but I don't know if he came to any definitive conclusions, such as implementing System Privileges as well as Object Privileges. If he does, then the dba (or anyone who has been granted GRANT ANY PRIVILEGE system privilege & CREATE USER system privilege) should be able to do: CREATE USER mascarm IDENTIFIED BY manager; GRANT CREATE TABLE to mascarm; It would also be good if PostgreSQL came with 2 groups by default - connect and dba. The connect group would be granted these System Privileges: CREATE AGGREGATE privilege CREATE INDEX privilege CREATE FUNCTION privilege CREATE OPERATOR privilege CREATE RULE privilege CREATE SESSION privilege CREATE SYNONYM privilege CREATE TABLE privilege CREATE TRIGGER privilege CREATE TYPE privilege CREATE VIEW privilege These allow the user to create the above objects in their own schema only. We're getting schemas in 7.2, right? ;-). The dba group would be granted the rest, like these: CREATE ANY AGGREGATE privilege CREATE ANY INDEX privilege... (and so on) as well as: CREATE/ALTER/DROP USER GRANT ANY PRIVILEGE COMMENT ANY TABLE INSERT ANY TABLE UPDATE ANY TABLE DELETE ANY TABLE SELECT ANY TABLE ANALYZE ANY TABLE LOCK ANY TABLE CREATE PUBLIC SYNONYM (needed when schemas roll around) DROP PUBLIC SYNONYM (and so on) Then, the dba could do a: GRANT connect TO mascarm; Or a: CREATE USER mascarm IDENTIFIED BY manager IN GROUP connect; It seems Karel's patch is a solution to the problem of people who want to create separate PostgreSQL user accounts, but want to ensure that a user can't create tables. In Oracle, I would just do a: CREATE USER mascarm IDENTIFIED BY manager; GRANT CREATE SESSION TO mascarm; Now mascarm has the ability to connect, but that's it. Currently, if I know for instance that a background process DROPS a table, CREATES a new one, and then imports some data, I can create my own table by the same name, in between the DROP and CREATE and can cause havoc (if its not done in a single transaction). Hopefully Peter E's ACL design will allow for Oracle-like System Privileges to take place. That would allow for a much finer granularity of permissions then everyone either being the Unix equivalent of 'root' or 'user'. Just my humble opinion though, Mike Mascari mascarm@mascari.com -----Original Message----- From: Bruce Momjian [SMTP:pgman@candle.pha.pa.us] Can someone remind me what we are going to do with this? [ Charset ISO-8859-2 unsupported, converting... ] > > On Fri, 26 Jan 2001, [koi8-r] ______ _. _______ wrote: > > > Good Day, Dear Karel Zak! > > > > Please, forgive me for my bad english and if i do not right with your > > day time. > > my English is more poor :-) > > You are right, it is (was?) in TODO and it will implemented - I hope - > in some next release (may be in 7.2 during ACL overhaul, Peter?). > > Before some time I wrote patch that resolve it for 7.0.2 (anyone - > I forgot his name..) port it to 7.0.2, my original patch was for 7.0.0. > May be will possible use it for last stable 7.0.3 too. > > The patch is at: > ftp://ftp2.zf.jcu.cz/users/zakkr/pg/7.0.2-user.patch.gz > > This patch add to 7.0.2 code NOCREATETABLE and NOLOCKTABLE feature: > > CREATE USER username > [ WITH > [ SYSID uid ] > [ PASSWORD 'password' ] ] > [ CREATEDB | NOCREATEDB ] [ CREATEUSER | NOCREATEUSER ] > -> [ CREATETABLE | NOCREATETABLE ] [ LOCKTABLE | NOLOCKTABLE ] > ...etc. > > If CREATETABLE or LOCKTABLE is not specific in CREATE USER command, > as default is set CREATETABLE or LOCKTABLE (true). > > > But, don't forget - it's temporarily solution, I hope that some next > release resolve it more systematic. More is in the patche@postgresql.org > archive where was send original patch. > > Because you are not first person that ask me, I re-post (CC:) it to > hackers@postgresql.org, more admins happy with this :-) > > Karel > > > I want to ask You about "access control over who can create tables and > > use locks in PostgreSQL". This message was placed in PostgreSQL site > > TODO list. But now it was deleted. I so need help about this question, > > becouse i'll making a site witch will give hosting for our users. > > And i want to make a PostgreSQL access to their own databases. But there > > is (how You now) one problem. Anyone user may to connect to the different > > user database and he may to create himself tables. > > I don't like it. > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 From tgl@sss.pgh.pa.us Mon May 7 17:33:41 2001 Return-path: Received: from sss.pgh.pa.us (tgl@sss.pgh.pa.us [216.151.103.158]) by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f47LXeu02566 for ; Mon, 7 May 2001 17:33:40 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.3/8.11.3) with ESMTP id f47LXgR23236; Mon, 7 May 2001 17:33:42 -0400 (EDT) To: Bruce Momjian cc: Karel Zak , =?KOI8-R?Q?=ED=C1=CB=D3=C9=CD_=ED=2E_=F0=CF=CC=D1=CB=CF=D7?= , pgsql-hackers Subject: Re: [HACKERS] NOCREATETABLE patch (was: Re: Please, help!(about Postgres)) In-Reply-To: <200105071848.f47ImBh20345@candle.pha.pa.us> References: <200105071848.f47ImBh20345@candle.pha.pa.us> Comments: In-reply-to Bruce Momjian message dated "Mon, 07 May 2001 14:48:11 -0400" Date: Mon, 07 May 2001 17:33:42 -0400 Message-ID: <23233.989271222@sss.pgh.pa.us> From: Tom Lane Status: OR Bruce Momjian writes: > Can someone remind me what we are going to do with this? I'd like to see some effort put into implementing the SQL-standard privilege model, rather than adding yet more ad-hoc user properties. The more of these we make, the more painful it's going to be to meet the spec later. Possibly, after we have the SQL semantics we'll still feel that we need some additional features ... but how about spec first and extensions afterwards? regards, tom lane From zakkr@zf.jcu.cz Wed May 9 05:12:41 2001 Return-path: Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4]) by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f499Cbu05406 for ; Wed, 9 May 2001 05:12:37 -0400 (EDT) Received: (from zakkr@localhost) by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) id LAA20000; Wed, 9 May 2001 11:12:35 +0200 Date: Wed, 9 May 2001 11:12:35 +0200 From: Karel Zak To: Bruce Momjian cc: pgsql-hackers Subject: Re: [HACKERS] NOCREATETABLE patch (was: Re: Please, help!(about Postgres)) Message-ID: <20010509111235.A18101@ara.zf.jcu.cz> References: <200105071848.f47ImBh20345@candle.pha.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <200105071848.f47ImBh20345@candle.pha.pa.us>; from pgman@candle.pha.pa.us on Mon, May 07, 2001 at 02:48:11PM -0400 Status: ORr On Mon, May 07, 2001 at 02:48:11PM -0400, Bruce Momjian wrote: > > Can someone remind me what we are going to do with this? > > > This patch add to 7.0.2 code NOCREATETABLE and NOLOCKTABLE feature: It's my old patch, it's usable and some people use it for 7.0.x. But it's really temporary solution and it was 1 day in official CVS :-) We remove it after discussion with Peter E. More correct will implement better privilege system. A privilege system is *very* important for real multiuser and sophisticated systems. For example if you compare PostgreSQL with Oracle, the PostgreSQL is really not winner in this part. Peter has some idea about it and Jan sent something about it too, but I not sure if somebody works on this and plannig it for some next release (or...? -- will good if I not right:-) Karel From pgsql-hackers-owner+M8485@postgresql.org Wed May 9 10:11:53 2001 Return-path: Received: from postgresql.org (webmail.postgresql.org [216.126.85.28]) by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f49EBqu24085 for ; Wed, 9 May 2001 10:11:52 -0400 (EDT) Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) by postgresql.org (8.11.3/8.11.1) with SMTP id f49EBiA44525; Wed, 9 May 2001 10:11:44 -0400 (EDT) (envelope-from pgsql-hackers-owner+M8485@postgresql.org) Received: from corvette.mascari.com (dhcp065-024-161-045.columbus.rr.com [65.24.161.45]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f49DVoA25183 for ; Wed, 9 May 2001 09:31:51 -0400 (EDT) (envelope-from mascarm@mascari.com) Received: from ferrari (ferrari.mascari.com [192.168.2.1]) by corvette.mascari.com (8.9.3/8.9.3) with SMTP id JAA11700; Wed, 9 May 2001 09:20:46 -0400 Received: by localhost with Microsoft MAPI; Wed, 9 May 2001 09:29:01 -0400 Message-ID: <01C0D86A.7B6E19C0.mascarm@mascari.com> From: Mike Mascari Reply-To: "mascarm@mascari.com" To: "'Zeugswetter Andreas SB'" , "'Bruce Momjian'" cc: Karel Zak , pgsql-hackers Subject: RE: [HACKERS] NOCREATETABLE patch (was: Re: Please, help!(about P ostgres)) Date: Wed, 9 May 2001 09:29:01 -0400 Organization: Mascari Development Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR That makes perfect sense to me. I was only going by what System Privileges are granted to the Oracle roles of the same name. Oracle has: CONNECT - ALTER SESSION CREATE CLUSTER CREATE DATABASE LINK CREATE SEQUENCE CREATE SESSION CREATE SYNONYM CREATE TABLE CREATE VIEW RESOURCE - CREATE CLUSTER CREATE PROCEDURE CREATE SEQUENCE CREATE TABLE CREATE TRIGGER DBA - All systems privileges WITH ADMIN OPTION But I agree with you. When I was first learning Oracle, I thought it strange that the CONNECT role had anything more than CREATE/ALTER SESSION privilege. Mike Mascari mascarm@mascari.com -----Original Message----- From: Zeugswetter Andreas SB [SMTP:ZeugswetterA@wien.spardat.at] Sent: Wednesday, May 09, 2001 3:20 AM To: 'Bruce Momjian'; mascarm@mascari.com Cc: Karel Zak; pgsql-hackers Subject: AW: [HACKERS] NOCREATETABLE patch (was: Re: Please, help!(about P ostgres)) > > The connect group would be granted these System Privileges: If we keep it like others (e.g. Informix) this System Privilege would be called "resource". I like this name better, because it more describes the detailed priviledges. > > > > CREATE AGGREGATE privilege > > CREATE INDEX privilege > > CREATE FUNCTION privilege > > CREATE OPERATOR privilege > > CREATE RULE privilege > > CREATE SESSION privilege > > CREATE SYNONYM privilege > > CREATE TABLE privilege > > CREATE TRIGGER privilege > > CREATE TYPE privilege > > CREATE VIEW privilege The "connect" group would only have the priviledge to connect to the db [and create temp tables ?] and rights they where granted, or that were granted to public. They would not be allowed to create anything. Andreas ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl From ZeugswetterA@wien.spardat.at Wed May 9 03:21:37 2001 Return-path: Received: from fizbanrsm.server.lan.at (zep4.it-austria.net [213.150.1.74]) by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f497LZu00341 for ; Wed, 9 May 2001 03:21:35 -0400 (EDT) Received: from gz0153.gc.spardat.at (gz0153.gc.spardat.at [172.20.10.149]) by fizbanrsm.server.lan.at (8.11.2/8.11.2) with ESMTP id f497LSl28442 for ; Wed, 9 May 2001 09:21:28 +0200 Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service (5.5.2650.21) id ; Wed, 9 May 2001 09:20:30 +0200 Message-ID: <11C1E6749A55D411A9670001FA6879633682BB@sdexcsrv1.f000.d0188.sd.spardat.at> From: Zeugswetter Andreas SB To: "'Bruce Momjian'" , mascarm@mascari.com cc: Karel Zak , pgsql-hackers Subject: AW: [HACKERS] NOCREATETABLE patch (was: Re: Please, help!(about P ostgres)) Date: Wed, 9 May 2001 09:20:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Status: OR > > The connect group would be granted these System Privileges: If we keep it like others (e.g. Informix) this System Privilege would be called "resource". I like this name better, because it more describes the detailed priviledges. > > > > CREATE AGGREGATE privilege > > CREATE INDEX privilege > > CREATE FUNCTION privilege > > CREATE OPERATOR privilege > > CREATE RULE privilege > > CREATE SESSION privilege > > CREATE SYNONYM privilege > > CREATE TABLE privilege > > CREATE TRIGGER privilege > > CREATE TYPE privilege > > CREATE VIEW privilege The "connect" group would only have the priviledge to connect to the db [and create temp tables ?] and rights they where granted, or that were granted to public. They would not be allowed to create anything. Andreas