Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check |
Дата | |
Msg-id | CA+TgmoY=HeN2yV1R0_NDqvMgdPPe2wYM=94dWDnb13npDpn1pQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check
|
Список | pgsql-hackers |
On Wed, Jan 25, 2017 at 2:08 PM, Stephen Frost <sfrost@snowman.net> wrote: > That isn't what you're doing with those functions though, you're giving > the monitoring tool superuser-level rights but trying to pretend like > you're not. Uh, how so? None of those functions can be used to escalate to superuser privileges. I am trying to give SOME superuser privileges and not others. That IS how good security works. I don't really think it's necessary to outline the use case more than I have already. It's perfectly reasonable to want a monitoring tool to have access to pg_ls_dir() - for example, you could use that to monitor for relation files orphaned by a previous crash. Also, as mentioned above, I don't think this should have to be litigated for every single function individually. If it's a good idea for a non-superuser to be able to pg_start_backup() and pg_stop_backup(), the person doing that has access to read every byte of data in the filesystem; if they don't, there's no point in giving them access to run those functions. Access to just pg_ls_dir(), for example, can't be any more dangerous than that. Indeed, I'd argue that it's a heck of a lot LESS dangerous. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: