Re: [PATCHES] Users/Groups -> Roles - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [PATCHES] Users/Groups -> Roles
Date
Msg-id 20050629002304.GT24207@ns.snowman.net
Whole thread Raw
In response to Re: [PATCHES] Users/Groups -> Roles  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Bruno Wolff III (bruno@wolff.to) wrote:
> >> Creating objects in particular schemas or databases is not something that
> >> all roles may be able to do.
>
> > Yeah, I'm not entirely sure what I think about this issue.
>
> We have a precedent, which is that RENAME checks for create rights.

Ah, ok.  Precedent is good.

> If you want to lean on the argument that this is just a shortcut for
> dropping the object and then recreating it somewhere else, then you
> need (a) the right to drop the object --- which is inherent in being
> the old owner, and (b) the right to create the new object, which means
> that (b1) you can become the role you wish to have owning the object,
> and (b2) *as that role* you would have the rights needed to create the
> object.
>
> Stephen's original analysis covers (a) and (b1) but not (b2).  With (b2)
> I'd agree that it's just a useful shortcut.

Right.  Ok, I'll develop a patch which covers (a), (b1) and (b2).  I'll
also go through all of the superuser() calls in src/backend/commands/
and check for other places we may need *_ownercheck calls.

I expect to have the patch done either tonight or tommorow.
    Thanks,
        Stephen

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: CVS pg_config --includedir-server broken
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Problem with dblink regression test - FIXED