From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCHES] Users/Groups -> Roles |
Date: | 2005-07-01 17:03:16 |
Message-ID: | 9992.1120237396@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Stupid question, but how do roles relate to our existing "groups"?
As committed, roles subsume both users and groups: a role that permits
login (rolcanlogin) acts as a user, and a role that has members is a
group. It is possible for the same role to do both things, though I'm
not sure that it's good security policy to set up a role that way.
The advantage over what we had is exactly that there isn't any
distinction, and thus groups can do everything users can and
vice versa:
* groups can own objects
* groups can contain other groups (we forbid loops though)
Also there is a notion of "admin option" for groups, which is like
"grant option" for privileges: you can designate certain members of
a group as being able to grant ownership in that group to others,
without having to make them superusers.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-07-01 17:06:29 | Re: [PATCHES] Users/Groups -> Roles |
Previous Message | Heikki Linnakangas | 2005-07-01 17:02:22 | Re: 2PC transaction id |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-07-01 17:06:29 | Re: [PATCHES] Users/Groups -> Roles |
Previous Message | Heikki Linnakangas | 2005-07-01 17:02:22 | Re: 2PC transaction id |