Обсуждение: Roles and Superusers

Greetings:

First, I apologize if this is not the correct list to
send to. I am having a problem with group roles, logon
roles, and inheritance. I am not sure if it is a
database problem or a pgIII problem. I am using
postgreSQL 8.1.4 and the bundled pgIII on WinXP Home
SP2.

It seems that the 'superuser' part of my 'leads' group
role is not functioning (code below). It appears that
the security settings are at least partially
transitive as I have one group role nested within the
other and I am able to access the appropriate
resources. The problem is that only a superuser or the
owner of a table can drop it and even though I am
supposed to be a superuser, I cannot drop the table! I
also lack the ability to create databases... The setup
is below.

I have setup two group roles

CREATE ROLE developers
  NOSUPERUSER INHERIT CREATEDB NOCREATEROLE;

and

CREATE ROLE leads
  SUPERUSER INHERIT CREATEDB CREATEROLE;
UPDATE pg_authid SET rolcatupdate=true WHERE
OID=23059::oid;
GRANT developers TO leads WITH ADMIN OPTION;

I also have a login role for myself

CREATE ROLE keith LOGIN
  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
GRANT leads TO keith WITH ADMIN OPTION;

Lastly I have a table to which only the owner and the
'developers' group role have access to. Public is not
listed. I can use this table freely, but not drop it.

CREATE TABLE test.files
(
  ...
)
WITHOUT OIDS;
ALTER TABLE test.files OWNER TO test;
GRANT ALL ON TABLE test.files TO test;
GRANT ALL ON TABLE test.files TO developers;

Thanks in advance for your help.

Sincerely,

Keith


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Keith <keithcelt@yahoo.com> writes:
> It seems that the 'superuser' part of my 'leads' group
> role is not functioning (code below). It appears that
> the security settings are at least partially
> transitive as I have one group role nested within the
> other and I am able to access the appropriate
> resources. The problem is that only a superuser or the
> owner of a table can drop it and even though I am
> supposed to be a superuser, I cannot drop the table!

Then you're not a superuser ;-)

I gather from your example that you are expecting superuserness to
inherit through role membership.  It doesn't, and neither do the
other "special" privileges managed via CREATE/ALTER ROLE.  It's
arguable whether this is a good policy for eg. CREATEDB, but personally
I think it's the right behavior for the superuser bit.  When you pass
out the keys to the kingdom, you want to pass 'em out one recipient
at a time, eh?

            regards, tom lane