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

Re: Grantor name gets lost when grantor role dropped

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Russell Smith <mr-russ(at)pws(dot)com(dot)au>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Grantor name gets lost when grantor role dropped
Date: 2007-04-17 12:51:15
Message-ID: 20070417125115.GB4660@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Russell Smith wrote:
> Alvaro Herrera wrote:
> >Jeff Davis wrote:
> >
> >  
> >>CREATE ROLE test_role
> >>  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
> >> 
> >>CREATE ROLE invalid_grantor
> >>  SUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
> >> 
> >>SET ROLE invalid_grantor;
> >>GRANT "postgres" TO "test_role";
> >>SET ROLE postgres;
> >> 
> >>select * from pg_roles;
> >> 
> >>select pg_auth_members.*, ur.rolname, gr.rolname from pg_auth_members 
> >>LEFT JOIN pg_roles ur ON roleid = oid
> >>LEFT JOIN pg_roles gr ON gr.oid = grantor;
> >> 
> >>DROP ROLE invalid_grantor;
> >> 
> >>select pg_auth_members.*, ur.rolname, gr.rolname from pg_auth_members 
> >>LEFT JOIN pg_roles ur ON roleid = oid
> >>LEFT JOIN pg_roles gr ON gr.oid = grantor;
> >> 
> >>DROP ROLE test_role;
> >>    
> >
> >The problem here is that we allowed the drop of invalid_grantor.  We are
> >missing a shared dependency on it.
> >  
> So does this make a todo item?
> 
> But this still leaves the concerns about you can currently get the 
> database into an invalid state that can't be dumped and restored.

Correct, which makes it a bug (==> needs fixed) rather than a todo item.

We now have a problem because there may already be databases that are
undumpable.  We might need to provide a workaround for people with such
a database.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2007-04-17 12:52:37
Subject: Python test failures
Previous:From: Marko KreenDate: 2007-04-17 11:08:12
Subject: Re: Buildfarm member Narwhal: Python 2.5/8.1

pgsql-bugs by date

Next:From: Jonathan VanascoDate: 2007-04-17 18:47:11
Subject: BUG #3234: pg_dump uses the first version of a primary key's name when generating reports
Previous:From: Dmitry BelyavskyDate: 2007-04-17 10:32:50
Subject: BUG #3233: Trigger checks failed on concurrent transactions

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