Re: [HACKERS] copying perms to another user
Added to TODO: * Add group object ownership, so groups can rename/drop/grant on objects, so we can implement roles --- Peter Eisentraut wrote: Bruce Momjian writes: I think the one missing item mentioned was for group ownership of an object. However, if we give group _permission_ to the object, I am not sure why ownership is an issue. Are there certain permission we can't give to the group? Privilege to rename or drop the object, and the right to grant privileges in the first place. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] copying perms to another user
Bruce Momjian writes: I think the one missing item mentioned was for group ownership of an object. However, if we give group _permission_ to the object, I am not sure why ownership is an issue. Are there certain permission we can't give to the group? Privilege to rename or drop the object, and the right to grant privileges in the first place. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] copying perms to another user
Christopher Kings-Lynne writes: We have roles? Until two days ago I was under the impression that roles were schema objects, but apparently this is not the case, and it seems that roles are really just an extension of our group concept. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] copying perms to another user
On Tue, Jan 14, 2003 at 12:23:59PM +0800, Christopher Kings-Lynne wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: No, I mean that we don't drop the user. You go: ALTER USER chriskl COPY PERMISSIONS FROM blah; That seems cleaner to me than the DROP thingy. You could only easily implement this in the current database --- but since it's not a DROP, one could repeat it in each database as needed. Could someone perhaps add it to TODO then (so I don't forget about it)? I can't promise that I can implement it... In this scenario, 'blah' is the user who will eventually be dropped, and chriskl is taking over ownership of his 'stuff' right? How about doing it the other way: ALTER USER blah COPY PERMISSIONS TO chriskl; Hmm, in fact, I can imagine uses for both forms: creating a 'template' user who you COPY PERMISSIONS FROM when creating a new user of that type, who will then be customized, so you can't use GROUPs. Hmm, what about GROUP membership? Those get copied as well? Ross ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] copying perms to another user
Christopher Kings-Lynne writes: Often I need to remove a user and cede their permissions to someone else. If this happens to you a lot, the solution is to implement roles, grant privileges to a role, grant the role to a user, and when you remove the user you grant the role to someone else. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] copying perms to another user
Ross J. Reedstrom [EMAIL PROTECTED] writes: On Tue, Jan 14, 2003 at 12:23:59PM +0800, Christopher Kings-Lynne wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: No, I mean that we don't drop the user. You go: ALTER USER chriskl COPY PERMISSIONS FROM blah; In this scenario, 'blah' is the user who will eventually be dropped, and chriskl is taking over ownership of his 'stuff' right? How about doing it the other way: ALTER USER blah COPY PERMISSIONS TO chriskl; That seems a bit bizarre to me. The user whose permissions are actually being altered by this command is chriskl, not blah, so ISTM chriskl is the name that should be specified as being ALTERed. In other words I like FROM, not TO. But: nearby, Peter E. complains that this is a poor substitute for implementing SQL-spec roles. He's got a point --- especially since roles could be made installation-wide, and thus they'd get around the problem that ALTER USER COPY couldn't realistically do anything about permissions in other databases. GRANT ROLE foo TO USER bar (or whatever the spec syntax is) would be an installation-wide change and so would indirectly grant any privileges the role has in other databases. While I haven't thought about it very hard, it seems to me that a role might be equivalent or nearly so to a group. If so, we might be able to support roles with little more than some syntactic-sugar work ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] copying perms to another user
While I haven't thought about it very hard, it seems to me that a role might be equivalent or nearly so to a group. If so, we might be able to support roles with little more than some syntactic-sugar work ... A few other changes, like allowing ownership of an object to be a group (role) rather than strictly a user. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] copying perms to another user
From: Rod Taylor [EMAIL PROTECTED] While I haven't thought about it very hard, it seems to me that a role might be equivalent or nearly so to a group. If so, we might be able to support roles with little more than some syntactic-sugar work ... A few other changes, like allowing ownership of an object to be a group (role) rather than strictly a user. Also, at least in Oracle, one can grant ROLEs to other ROLEs. I don't know if that is what the SQL standard says though: GRANT role1 TO role2; Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] copying perms to another user
We have roles? -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 15 January 2003 1:16 AM To: Christopher Kings-Lynne Cc: Hackers Subject: Re: [HACKERS] copying perms to another user Christopher Kings-Lynne writes: Often I need to remove a user and cede their permissions to someone else. If this happens to you a lot, the solution is to implement roles, grant privileges to a role, grant the role to a user, and when you remove the user you grant the role to someone else. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] copying perms to another user
On Mon, 2003-01-13 at 21:40, Christopher Kings-Lynne wrote: Often I need to remove a user and cede their permissions to someone else. How about something like this: DROP USER blah PERMISSIONS TO chriskl; If you check that it's a superuser doing the drop, this would be good. However, what (and how many) databases will this command work on? Only the current one? All of them? -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] copying perms to another user
On Mon, 2003-01-13 at 21:40, Christopher Kings-Lynne wrote: Often I need to remove a user and cede their permissions to someone else. How about something like this: DROP USER blah PERMISSIONS TO chriskl; If you check that it's a superuser doing the drop, this would be good. However, what (and how many) databases will this command work on? Only the current one? All of them? Yeah good point...it wouldn't bother me if it were just current database, except that then it wouldn't be useful to use the DROP USER command. ALTER USER or GRANT would be better. BTW Rod, I now get all your emails just fine (not as attachements) - did you change something? Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] copying perms to another user
Yeah good point...it wouldn't bother me if it were just current database, except that then it wouldn't be useful to use the DROP USER command. ALTER USER or GRANT would be better. How do you ALTER USER ... after they've been dropped? BTW Rod, I now get all your emails just fine (not as attachements) - did you change something? Not that I know of. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] copying perms to another user
Yeah good point...it wouldn't bother me if it were just current database, except that then it wouldn't be useful to use the DROP USER command. ALTER USER or GRANT would be better. How do you ALTER USER ... after they've been dropped? No, I mean that we don't drop the user. You go: ALTER USER chriskl COPY PERMISSIONS FROM blah; Sort of thing... Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] copying perms to another user
Christopher Kings-Lynne [EMAIL PROTECTED] writes: No, I mean that we don't drop the user. You go: ALTER USER chriskl COPY PERMISSIONS FROM blah; That seems cleaner to me than the DROP thingy. You could only easily implement this in the current database --- but since it's not a DROP, one could repeat it in each database as needed. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] copying perms to another user
Christopher Kings-Lynne [EMAIL PROTECTED] writes: No, I mean that we don't drop the user. You go: ALTER USER chriskl COPY PERMISSIONS FROM blah; That seems cleaner to me than the DROP thingy. You could only easily implement this in the current database --- but since it's not a DROP, one could repeat it in each database as needed. Could someone perhaps add it to TODO then (so I don't forget about it)? I can't promise that I can implement it... Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
