Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group