Re: BUG #5763: pg_hba.conf not honored - Mailing list pgsql-bugs

From Robert Haas
Subject Re: BUG #5763: pg_hba.conf not honored
Date
Msg-id AANLkTinfE4b3EHJDyM20+7cfGyRuV7yJSBimsBfJrrH6@mail.gmail.com
Whole thread Raw
In response to Re: BUG #5763: pg_hba.conf not honored  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Sun, Nov 28, 2010 at 11:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Nov 23, 2010 at 10:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I believe the definition of "in role" we use here is "has the privileges
>>> of role". =A0Since kaiting.chen is a superuser, all privilege tests will
>>> succeed for him, including that one. =A0IOW, a superuser is automatical=
ly
>>> a member of every role. =A0This 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. =A0Not sure how that would be less surprising.

=46rom 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.

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #5763: pg_hba.conf not honored
Next
From: "Shafqat Ali"
Date:
Subject: Re: BUG #5771: C:\Program Files\PostgreSQL\8.3\Data is not accessible.