Re: BUG #5763: pg_hba.conf not honored

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kaiting Chen <kaitocracy(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5763: pg_hba.conf not honored
Date: 2010-11-29 02:11:35
Message-ID: AANLkTinfE4b3EHJDyM20+7cfGyRuV7yJSBimsBfJrrH6@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message AI Rumman 2010-11-29 10:27:05 Full Text index is not using during OR operation for multiple table join
Previous Message Shafqat Ali 2010-11-29 01:45:06 Re: BUG #5771: C:\Program Files\PostgreSQL\8.3\Data is not accessible.