Re: [HACKERS] Simplify ACL handling for large objects and removal ofsuperuser() checks
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Simplify ACL handling for large objects and removal ofsuperuser() checks |
Дата | |
Msg-id | CA+TgmoasNa+gFWoNuQMKwpDePkJQ94FpZvPYL11tSWAfTi0OzQ@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] Simplify ACL handling for large objects and removal ofsuperuser() checks
|
Список | pgsql-hackers |
On Sun, Aug 13, 2017 at 11:20 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > Recent commit 8d98819 has added a missing permissoin check to lo_put() > to make sure that the write permissions of the object are properly set > before writing to a large object. When studying the problem, we bumped > into the fact that it is possible to actually simplify those ACL > checks and replace them by checks when opening the large object. This > makes all the checks now in be-fsstubs.c happen in inv_api.c, which is > where all the large object handling happens at a lower level. This > way, it is also possible to remove the extra logic in place to have > the permission checks happen only once. > > At the same time, we have bumped into two things: > - ALLOW_DANGEROUS_LO_FUNCTIONS has been introduced in 1999, so it > could be time to let it go. I have known of no place where this is > actively used. > - lo_import and lo_export on the backend have superuser checks. We > could remove them and replace them with proper REVOKE permissions to > allow administrators to give access to those functions. > > Attached is a set of 3 patches: > - 0001 removes ALLOW_DANGEROUS_LO_FUNCTIONS > - 0002 replaces the superuser checks with GRANT permissions +1 for 0001 and 0002 in general, but I can't help noticing that they lead to a noticeable worsening of the error messages in the regression tests. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: