Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Users/Groups -> Roles

From: "Michael Paesold" <mpaesold(at)gmx(dot)at>
To: "Stephen Frost" <sfrost(at)snowman(dot)net>,"Bruno Wolff III" <bruno(at)wolff(dot)to>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] Users/Groups -> Roles
Date: 2005-06-28 20:31:00
Message-ID: 00e601c57c20$4c255580$0f01a8c0@zaphod (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Stephen Frost wrote:
> If you're considered the owner of an object then you have access to drop
> it already.  You have to be a member of the role to which you're
> changing the ownership.  That role not having permission to create the
> object in place is an interesting question.  That's an issue for SET
> ROLE too, to some extent I think, do you still have your role's
> permissions after you've SET ROLE to another role?

For me this would be the "natural" way how SET ROLE would behave. This is 
unix'ism again, but using setuid to become another user, you loose the 
privileges of the old user context.
Therefore SET ROLE should not inherit privileges from the other role. This 
seems to be the safes approach.

Nevertheless, what does the standard say?

> If not then you'd
> have to grant CREATE on the schema to the role in order to create
> objects owned by that role, and I don't think that's necessairly
> something you'd want to do.

Right, that's an issue. But since the new role will be the *owner* of the 
object, it *should* really have create-privileges in that schema. So the 
above way seems to be correct anyway.

Best Regards,
Michael Paesold 


In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2005-06-28 20:33:16
Subject: Re: [HACKERS] Proposed TODO: --encoding option for pg_dump
Previous:From: Magnus HaganderDate: 2005-06-28 20:24:19
Subject: Re: [HACKERS] Proposed TODO: --encoding option for pg_dump

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2005-06-28 20:33:16
Subject: Re: [HACKERS] Proposed TODO: --encoding option for pg_dump
Previous:From: Magnus HaganderDate: 2005-06-28 20:24:19
Subject: Re: [HACKERS] Proposed TODO: --encoding option for pg_dump

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group