Обсуждение: BUG #5763: pg_hba.conf not honored
The following bug has been logged online:
Bug reference: 5763
Logged by: Kaiting Chen
Email address: kaitocracy@gmail.com
PostgreSQL version: 9.0.1
Operating system: Arch Linux (latest)
Description: pg_hba.conf not honored
Details:
### /etc/postgresql/pg_hba.conf: Authentication configuration for
'postgresql'
# Type Database User CIDR-ADDRESS Method
local all psql ident
host all +service 192.168.162.130/32 password
host all all 192.168.162.130/32 gss
### /etc/postgresql/pg_hba.conf: Authentication configuration for
'postgresql'
List of roles
Role name | Attributes | Member of
-------------------+-----------------------------------+-----------
kaiting.chen | Superuser, Create role, Create DB | {turtle}
psql | Superuser, Create role, Create DB | {}
service | | {}
turtle | | {}
---
kaiting.chen ~: PGHOST='psql.kiwilight.com' psql
Password:
psql: fe_sendauth: no password supplied
From this pg_hba configuration as the user 'kaiting.chen' is not in role
'service' the second entry in the table should be skipped and he should
authenticate via GSSAPI. However this does not happen.
### /etc/postgresql/pg_hba.conf: Authentication configuration for
'postgresql'
# Type Database User CIDR-ADDRESS Method
local all psql ident
host all +turtle 192.168.162.130/32 gss
host all all 192.168.162.130/32 password
### /etc/postgresql/pg_hba.conf: Authentication configuration for
'postgresql'
List of roles
Role name | Attributes | Member of
-------------------+-----------------------------------+-----------
kaiting.chen | Superuser, Create role, Create DB | {}
psql | Superuser, Create role, Create DB | {}
service | | {}
turtle | | {}
---
kaiting.chen ~: PGHOST='psql.kiwilight.com' psql
psql (9.0.1)
Type "help" for help.
kaiting.chen=#
From this pg_hba configuration as the user 'kaiting.chen' is no longer in
the role 'turtle' the second entry in the table should be skipped and he
should authenticate via password. However he is granted access to the
server.
Either I am missing something very obvious or this is completely broken.
--Kaiting.
"Kaiting Chen" <kaitocracy@gmail.com> writes:
> From this pg_hba configuration as the user 'kaiting.chen' is not in role
> 'service' the second entry in the table should be skipped and he should
> authenticate via GSSAPI. However this does not happen.
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.
regards, tom lane
On Tue, Nov 23, 2010 at 10:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kaiting Chen" <kaitocracy@gmail.com> writes: >> From this pg_hba configuration as the user 'kaiting.chen' is not in role >> 'service' the second entry in the table should be skipped and he should >> authenticate via GSSAPI. However this does not happen. > > 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 automatically > 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. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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". 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.
regards, tom lane
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
On sön, 2010-11-28 at 07:56 -0500, Robert Haas wrote: > 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. I agree this is pretty confusing and would consider changing it.