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

Re: ACLs versus ALTER OWNER

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ACLs versus ALTER OWNER
Date: 2004-06-02 15:13:38
Message-ID: 20040602151338.GA8754@dcc.uchile.cl (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Jun 02, 2004 at 10:54:36PM +0800, Christopher Kings-Lynne wrote:
> >Well, the spec doesn't have create permissions per se, but they do have
> >a "usage" right on domains, and they specify that revoking that results
> >in dropping objects:
> >
> >         7) For every abandoned domain descriptor DO, let S1.DN be the
> >            <domain name> of DO. The following <drop domain statement> is
> >            effectively executed without further Access Rule checking:
> >
> >              DROP DOMAIN S1.DN CASCADE
> 
> Hmmm.  Seems pretty harsh.  But barring us implementing that (I don't 
> see it happening for 7.5), just had an idea :)
> 
> How about pg_dumpall dumps all users as superusers, and then changes 
> them back to what they're supposed to be at the bottom of the script :)

Huh, how about a GUC var, say "creating_user", which would make objects
created by the superuser as created by whoever is mentioned there?  The
dump connects only as superuser and changes creating_user as needed.

Not a pretty idea, but weren't you looking for kludges? :-)

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La persona que no querĂ­a pecar / estaba obligada a sentarse
en duras y empinadas sillas    / desprovistas, por cierto
de blandos atenuantes"                          (Patricio Vogel)


In response to

pgsql-hackers by date

Next:From: Frank WilesDate: 2004-06-02 15:20:02
Subject: Re: Converting postgresql.conf parameters to kilobytes
Previous:From: Tom LaneDate: 2004-06-02 15:12:31
Subject: Re: Nested transactions and tuple header info

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