Re: permission to create user

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

In response to

Responses

Browse pgsql-general by date

  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