From: | Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: permission to create user |
Date: | 2006-07-18 13:53:17 |
Message-ID: | 1153230797.6928.48.camel@model.home.waw.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 2006-07-18 at 07:31 -0600, Michael Fuhr wrote:
> On Tue, Jul 18, 2006 at 01:45:01PM +0200, Rafal Pietrak wrote:
> > Any one knows, why do I have to explicitly SET ROLE, when I try to
> > exercise the group priviledge of role creation, while I don't need that
> > when accessing tables? Is this a feature, or a bug?
>
> http://www.postgresql.org/docs/8.1/interactive/role-membership.html
>
> "The role attributes LOGIN, SUPERUSER, CREATEDB, and CREATEROLE can
> be thought of as special privileges, but they are never inherited
> as ordinary privileges on database objects are. You must actually
> SET ROLE to a specific role having one of these attributes in order
> to make use of the attribute. Continuing the above example, we
> might well choose to grant CREATEDB and CREATEROLE to the admin
> role. Then a session connecting as role joe would not have these
> privileges immediately, only after doing SET ROLE admin."
Thenx. So it's a feature (it is documented).
My appology if the following question is naive, but digging it a bit
more:
Is it a feature, because it should be that way.... why? (standard says
so?) ...or it's a feature because it's documented: "Although we'd like
it to work like priviledges work on tables, current server-side
framework does not allow us to impolement it that way."
In other words:
1) is the discrepancy by design (why?) or
2) is it by accident - just results from development history.
--
-R
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Rengstl | 2006-07-18 14:28:38 | Antw: Re: Performance problem with query |
Previous Message | Timothy Smith | 2006-07-18 13:45:42 | Re: permission to create user |