Re: ALTER ROLE/DATABASE RESET ALL versus security
От | Alvaro Herrera |
---|---|
Тема | Re: ALTER ROLE/DATABASE RESET ALL versus security |
Дата | |
Msg-id | 20100318154857.GA3883@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: ALTER ROLE/DATABASE RESET ALL versus security (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: ALTER ROLE/DATABASE RESET ALL versus security
|
Список | pgsql-hackers |
Bruce Momjian wrote: > Alvaro Herrera wrote: > > Tom Lane wrote: > > > Alvaro Herrera <alvherre@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
Вложения
В списке pgsql-hackers по дате отправления: