ALTER ROLE/DATABASE RESET ALL versus security
in [PgSql]
|
Prev: LATERAL
Next: [HACKERS] Directory fsync and other fun
From: Tom Lane on 18 Mar 2010 11:59 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > 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. I think you still want to have a code path whereby the tuple will be deleted once the array is empty. Failing to check that is inefficient and also exposes clients such as pg_dump to corner case bugs. 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 25 Mar 2010 11:11
Tom Lane wrote: > Alvaro Herrera <alvherre(a)commandprompt.com> writes: > > 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. > > I think you still want to have a code path whereby the tuple will be > deleted once the array is empty. Failing to check that is inefficient > and also exposes clients such as pg_dump to corner case bugs. Yeah, that's there too -- it behaves the same way as ALTER / RESET for a particular setting. I just applied it all the way back to 7.4. It was a bit of a pain to backport it, because every version seemed to have this or that little incompatibility. I attempted a regression test, but it's also painful because there's no nice way to clean up after a newly created user (i.e. drop it): after the last \c - regress_user_guc, there's no way to go back to the original user. And we can't use SET SESSION AUTHORIZATION because it doesn't cause the settings for the role to be loaded. (I think that's a bug too). Suggestions on how to enable this are welcome. -- Test user-specific settings create role regress_user_guc login; alter role regress_user_guc set work_mem to '128MB'; alter role regress_user_guc set lc_messages to 'C'; \c - regress_user_guc select name, setting, source from pg_settings where name in ('work_mem', 'lc_messages') order by name; alter role regress_user_guc reset all; \c - regress_user_guc -- can't display actual value here because it may be installation-dependant select name, setting, source from pg_settings where name in ('work_mem', 'lc_messages') order by name; (I think I should also use a superuser setting other than lc_messages). -- 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 |