ALTER ROLE/DATABASE RESET ALL versus security
in [PgSql]
|
Prev: LATERAL
Next: [HACKERS] Directory fsync and other fun
From: Alvaro Herrera on 19 Feb 2010 13:22 Tom Lane wrote: > It looks to me like the code in AlterSetting() will allow an ordinary > user to blow away all settings for himself. Even those that are for > SUSET variables and were presumably set for him by a superuser. Isn't > this a security hole? I would expect that an unprivileged user should > not be able to change such settings, not even to the extent of > reverting to the installation-wide default. Yes, it is, but this is not a new hole. This works just fine in 8.4 too: alvherre=# create role foo; CREATE ROLE alvherre=# alter role foo set lc_messages = 'C'; ALTER ROLE alvherre=# set session AUTHORIZATION foo; SET alvherre=> show lc_messages ; lc_messages ------------- es_CL.UTF-8 (1 fila) alvherre=> alter role foo reset all; ALTER ROLE alvherre=> reset session AUTHORIZATION ; RESET alvherre=# set session AUTHORIZATION foo; SET alvherre=> show lc_messages ; lc_messages ------------- es_CL.UTF-8 (1 fila) alvherre=> alter role foo set lc_messages to 'C'; ERROR: se ha denegado el permiso para cambiar la opci�n �lc_messages� So any user is able to reset settings that were set for him by the superuser. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 19 Feb 2010 13:30 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > Tom Lane wrote: >> It looks to me like the code in AlterSetting() will allow an ordinary >> user to blow away all settings for himself. Even those that are for >> SUSET variables and were presumably set for him by a superuser. Isn't >> this a security hole? I would expect that an unprivileged user should >> not be able to change such settings, not even to the extent of >> reverting to the installation-wide default. > Yes, it is, but this is not a new hole. This works just fine in 8.4 > too: So I'd argue for changing it in 8.4 too. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 19 Feb 2010 13:41 Tom Lane wrote: > Alvaro Herrera <alvherre(a)commandprompt.com> writes: > > Tom Lane wrote: > >> It looks to me like the code in AlterSetting() will allow an ordinary > >> user to blow away all settings for himself. Even those that are for > >> SUSET variables and were presumably set for him by a superuser. Isn't > >> this a security hole? I would expect that an unprivileged user should > >> not be able to change such settings, not even to the extent of > >> reverting to the installation-wide default. > > > Yes, it is, but this is not a new hole. This works just fine in 8.4 > > too: > > So I'd argue for changing it in 8.4 too. Understood. I'm starting to look at what this requires. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 26 Feb 2010 22:38 Alvaro Herrera wrote: > Tom Lane wrote: > > Alvaro Herrera <alvherre(a)commandprompt.com> writes: > > > Tom Lane wrote: > > >> It looks to me like the code in AlterSetting() will allow an ordinary > > >> user to blow away all settings for himself. Even those that are for > > >> SUSET variables and were presumably set for him by a superuser. Isn't > > >> this a security hole? I would expect that an unprivileged user should > > >> not be able to change such settings, not even to the extent of > > >> reverting to the installation-wide default. > > > > > Yes, it is, but this is not a new hole. This works just fine in 8.4 > > > too: > > > > So I'd argue for changing it in 8.4 too. > > Understood. I'm starting to look at what this requires. Any progress on this? -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 18 Mar 2010 11:48
Bruce Momjian wrote: > Alvaro Herrera wrote: > > Tom Lane wrote: > > > Alvaro Herrera <alvherre(a)commandprompt.com> writes: > > > > Tom Lane wrote: > > > >> It looks to me like the code in AlterSetting() will allow an ordinary > > > >> user to blow away all settings for himself. Even those that are for > > > >> SUSET variables and were presumably set for him by a superuser. Isn't > > > >> this a security hole? I would expect that an unprivileged user should > > > >> not be able to change such settings, not even to the extent of > > > >> reverting to the installation-wide default. > > > > > > > Yes, it is, but this is not a new hole. This works just fine in 8.4 > > > > too: > > > > > > So I'd argue for changing it in 8.4 too. > > > > Understood. I'm starting to look at what this requires. > > Any progress on this? I have come up with the attached patch. I haven't tested it fully yet, and I need to backport it. The gist of it is: we can't simply remove the pg_db_role_setting tuple, we need to ask GUC to reset the settings array, for which it checks superuser-ness on each setting. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support |