DROP ROLE dependency tracking ...
good morning,
some days ago i have fallen over an issue which feels more or less like
a bug. consider:
test=# create role xy LOGIN;
CREATE ROLE
test=# grant connect on database test to xy;
GRANT
test=# drop role xy;
ERROR: role "xy" cannot be dropped because some objects depend on it
DETAIL: access to database test
this is a totally fresh instance --- all i did was creating a db called
"test".
failing would make sense if i would the owner of an object but i fact i
don't own anything.
test=# SELECT version();
version
----------------------------------------------------------------------------------------------------------
PostgreSQL 8.4devel on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
(1 row)
is this a known issue?
many thanks,
hans
--
Cybertec Sch�nig & Sch�nig GmbH
PostgreSQL Solutions and Support
Gr�hrm�hlgasse 26, A-2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql-support.de, www.postgresql-support.com
Hans-Juergen Schoenig wrote:
test=# create role xy LOGIN;
CREATE ROLEtest=# grant connect on database test to xy;
GRANTtest=# drop role xy;
ERROR: role "xy" cannot be dropped because some objects depend on it
DETAIL: access to database testthis is a totally fresh instance --- all i did was creating a db called
"test".
failing would make sense if i would the owner of an object but i fact i
don't own anything.
But in some cases you might not want to lose the information associated
to the grants you've done. That's why we have REASSIGN OWNED.
Hmm, but then there's no way to lose it, even if you do want that. DROP
OWNED does not touch grants (which is per design), but we don't have
DROP ROLE CASCADE. So maybe there's a functionality gap here ...
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
test=# create role xy LOGIN;
CREATE ROLEtest=# grant connect on database test to xy;
GRANTtest=# drop role xy;
ERROR: role "xy" cannot be dropped because some objects depend on it
DETAIL: access to database testthis is a totally fresh instance --- all i did was creating a db called
"test".
failing would make sense if i would the owner of an object but i fact i
don't own anything.But in some cases you might not want to lose the information associated
to the grants you've done. That's why we have REASSIGN OWNED.Hmm, but then there's no way to lose it, even if you do want that. DROP
OWNED does not touch grants (which is per design), but we don't have
DROP ROLE CASCADE. So maybe there's a functionality gap here ...
when thinking of REASSIGNED OWNED people tend to think about tables
rather than about CONNECT rights.
i would suggest to make DROP ROLE just kill the role unless there is a
real object depending on it.
i would not see a permission to be an object. what do you think?
many thanks,
hans
--
Cybertec Sch�nig & Sch�nig GmbH
PostgreSQL Solutions and Support
Gr�hrm�hlgasse 26, A-2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql-support.de, www.postgresql-support.com
Hans-Juergen Schoenig wrote:
when thinking of REASSIGNED OWNED people tend to think about tables
rather than about CONNECT rights.
i would suggest to make DROP ROLE just kill the role unless there is a
real object depending on it.
i would not see a permission to be an object. what do you think?
Yes, this might make some sense. (Keep in mind that db CONNECT
privileges were invented after REASSIGN OWNED). Perhaps we could make
exceptions -- in which case it would be good to investigate which
exceptions we need (i.e. for all object types that we support, which
ones we should be caring about and which ones we should ignore).
I'm stuck in Canuckistan for a week still, so I expect your detailed
proposal by when I get back home ;-)
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
when thinking of REASSIGNED OWNED people tend to think about tables
rather than about CONNECT rights.
i would suggest to make DROP ROLE just kill the role unless there is a
real object depending on it.
i would not see a permission to be an object. what do you think?Yes, this might make some sense. (Keep in mind that db CONNECT
privileges were invented after REASSIGN OWNED). Perhaps we could make
exceptions -- in which case it would be good to investigate which
exceptions we need (i.e. for all object types that we support, which
ones we should be caring about and which ones we should ignore).I'm stuck in Canuckistan for a week still, so I expect your detailed
proposal by when I get back home ;-)
Where are we on this issue? The original issue was CONNECT priviledges
prevented the role from being dropped.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
when thinking of REASSIGNED OWNED people tend to think about tables
rather than about CONNECT rights.
i would suggest to make DROP ROLE just kill the role unless there is a
real object depending on it.
i would not see a permission to be an object. what do you think?Yes, this might make some sense. (Keep in mind that db CONNECT
privileges were invented after REASSIGN OWNED). Perhaps we could make
exceptions -- in which case it would be good to investigate which
exceptions we need (i.e. for all object types that we support, which
ones we should be caring about and which ones we should ignore).I'm stuck in Canuckistan for a week still, so I expect your detailed
proposal by when I get back home ;-)
Was there any progress on this?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
when thinking of REASSIGNED OWNED people tend to think about tables
rather than about CONNECT rights.
i would suggest to make DROP ROLE just kill the role unless there is a
real object depending on it.
i would not see a permission to be an object. what do you think?Yes, this might make some sense. (Keep in mind that db CONNECT
privileges were invented after REASSIGN OWNED). Perhaps we could make
exceptions -- in which case it would be good to investigate which
exceptions we need (i.e. for all object types that we support, which
ones we should be caring about and which ones we should ignore).I'm stuck in Canuckistan for a week still, so I expect your detailed
proposal by when I get back home ;-)Was there any progress on this?
Not from my side --- and Hans-Juergen never got back to me either ...
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Added to TODO:
Allow dropping of a role that has connection rights
* http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php
---------------------------------------------------------------------------
Hans-Juergen Schoenig wrote:
good morning,
some days ago i have fallen over an issue which feels more or less like
a bug. consider:test=# create role xy LOGIN;
CREATE ROLEtest=# grant connect on database test to xy;
GRANTtest=# drop role xy;
ERROR: role "xy" cannot be dropped because some objects depend on it
DETAIL: access to database testthis is a totally fresh instance --- all i did was creating a db called
"test".
failing would make sense if i would the owner of an object but i fact i
don't own anything.test=# SELECT version();
version
----------------------------------------------------------------------------------------------------------
PostgreSQL 8.4devel on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
(1 row)is this a known issue?
many thanks,
hans
--
Cybertec Sch?nig & Sch?nig GmbH
PostgreSQL Solutions and Support
Gr?hrm?hlgasse 26, A-2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql-support.de, www.postgresql-support.com--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +