Обсуждение: 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.