On Sun, Nov 28, 2010 at 11:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Nov 23, 2010 at 10:29 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I believe the definition of "in role" we use here is "has the privileges
>>> of role". Since kaiting.chen is a superuser, all privilege tests will
>>> succeed for him, including that one. IOW, a superuser is automatically
>>> a member of every role. This isn't a bug.
>> I guess it's not a bug if we did it that way on purpose, but it seems
>> like testing for actual group membership would be less surprising.
> Then you'd have superusers acting like they were group members for some
> purposes and not others. Not sure how that would be less surprising.
From a permissions perspective, the superuser's power ought to be
defined as "bypasses all permissions checks" rather than "has
privileges of every role", even though having some code that does the
latter may be useful as an implementation detail. Here it seems to me
roles are being used for grouping, not permissions checking. Think in
particular about a reject rule for a certain group of users.
The Enterprise PostgreSQL Company
In response to
pgsql-bugs by date
|Next:||From: AI Rumman||Date: 2010-11-29 10:27:05|
|Subject: Full Text index is not using during OR operation for multiple table join|
|Previous:||From: Shafqat Ali||Date: 2010-11-29 01:45:06|
|Subject: Re: BUG #5771: C:\Program Files\PostgreSQL\8.3\Data is not accessible.|