Re: [PATCHES] Users/Groups -> Roles

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Fabien COELHO <fabien(dot)coelho(at)ensmp(dot)fr>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] Users/Groups -> Roles
Date: 2005-06-28 16:13:59
Message-ID: 20050628161358.GH24207@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Hi Fabien,

* Fabien COELHO (fabien(dot)coelho(at)ensmp(dot)fr) wrote:
> I've looked very quickly at the patch. ISTM that the proposed patch is a
> reworking of the user/group stuff, which are both unified for a new "role"
> concept where a user is a kind of role and a role can be a member of
> another role. Well, why not.

Right, it's a beginning to proper 'Role' support as defined by the SQL
specification.

> Some added files seems not to be provided in the patch :

pg_authid.h and pg_auth_members.h were attached to the email. They're
also available at http://kenobi.snowman.net/~sfrost/pg_role/ ; but the
patch has already been applied by Tom to CVS HEAD (well, with lots of
modifications and whatnot), so you probably should just take a look at
that.

> Anyway, from what I can see in the patch it seems that the roles are per
> cluster, and not per catalog. So this is not so conceptually different
> from user/group as already provided in pg.

It's conceptually different from users/groups in that it's roles, which
aren't the same thing. You're right, it's still per-cluster though.

> What would have been much more interesting for me would be a per catalog
> role, so that rights could be administrated locally in each database. I'm
> not sure how to provide such a feature, AFAICS the current version does
> not give me new abilities wrt right management.

I understand your concerns here and while I agree with the basic idea
that per-catalog role sets would be nice it wasn't what I had set out to
do with this patch. Perhaps what you're asking for will be added later
on. Some things this patch does do though are:

Allow role ownership. This role can also have members, and doesn't
necessairly have to be allowed to log in. Members of a role which owns
an object have owner-level rights on that object (so, fe: roles user1,
user2 and group1 where user1 and user2 are members of group1, a table
owned by group1 can be vacuumed, have columns added/removed, have
indexes create on it, etc, by user1 or user2).

Allow granting roles to other roles based on the 'with admin option'.
This means you don't have to be a superuser to add a member to a role
which you have the 'admin option' on.

There's other things (startup may be a bit faster since the pg_auth file
is sorted by the backend instead of during each startup, etc) but the
above were the types of things that I was looking to do mainly.

I'd like to see it possible to distinguish between 'superuser' and
'createrole' permissions, but I didn't get to that point with the roles
support (it's really a seperate issue anyway).

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2005-06-28 16:15:46 Re: Problem with dblink regression test
Previous Message Stephen Frost 2005-06-28 16:04:14 Re: [PATCHES] Users/Groups -> Roles

Browse pgsql-patches by date

  From Date Subject
Next Message Jim C. Nasby 2005-06-28 16:15:46 Re: Problem with dblink regression test
Previous Message Stephen Frost 2005-06-28 16:04:14 Re: [PATCHES] Users/Groups -> Roles