Re: [PATCHES] Users/Groups -> Roles

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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