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

Re: ACLs versus ALTER OWNER

From: John Hansen <john(at)geeknet(dot)com(dot)au>
To: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Subject: Re: ACLs versus ALTER OWNER
Date: 2004-06-02 10:23:00
Message-ID: 1086171780.1877.9.camel@localhost (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 2004-06-02 at 18:44, Christopher Kings-Lynne wrote:
> > REVOKE ALL ON TABLE foo FROM GRANTOR [USER] alice;
> > 
> > The super user must really be a *super* user.
> 
> I think we need a proper 'effective user' facility.
> 
> At the moment, there's breakage if a super user creates a language, then 
> drops their superuser privs, then the dump cannot be restored.
> 
> All other failure cases also exist.  eg if a gumby user creates a table 
> in a schema, then has his permission to create tables in that schema 
> revoked.  The dump will be broken.
> 
> The solution seems to me that we need to have an 'effective_user' SET 
> option so that the superuser doing the restore can still create tables 
> owned by the gumby, even though the gumby does not have privileges to do 
>   so.

If I remember correctly, we already have this option.
ALTER table OWNER to newowner;
Perhaps pg_dump should just include; ALTER relation OWNER to
originalowner; at the end of the dump, instead of connecting as the
owner to restore it.

> 
> Chris
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>       message can get through to the mailing list cleanly

Regards,

John

In response to

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2004-06-02 12:07:23
Subject: Re: [pgsql-hackers-win32] select like...not using index
Previous:From: Christopher Kings-LynneDate: 2004-06-02 09:56:30
Subject: Re: query INSERT OR REPLACE

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