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+TgmoYoCm4mHi6F34ToGwdhBDJHO+vYOMdKzCfrBYneZ5+2bQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superusercheck (David Fetter <david@fetter.org>) |
Ответы |
Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superusercheck
|
Список | pgsql-hackers |
On Sun, Jan 29, 2017 at 5:39 PM, David Fetter <david@fetter.org> wrote: > On Thu, Jan 26, 2017 at 08:50:27AM -0500, Robert Haas wrote: >> On Wed, Jan 25, 2017 at 10:31 PM, Stephen Frost <sfrost@snowman.net> wrote: >> > Frankly, I get quite tired of the argument essentially being made >> > here that because pg_ls_dir() wouldn't grant someone superuser >> > rights, that we should remove superuser checks from everything. >> > As long as you are presenting it like that, I'm going to be quite >> > dead-set against any of it. >> 1. pg_ls_dir. I cannot see how this can ever be used to get >> superuser privileges. > > With pilot error, all things are possible. A file name under $PGDATA > could be the superuser password. Uh, true. The default value of application_name could be the superuser password, too, but we still allow access to it by unprivileged users. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: