Re: Simplify ACL handling for large objects and removal of superuser() checks

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Simplify ACL handling for large objects and removal of superuser() checks
Date: 2017-08-15 13:35:51
Message-ID: CA+TgmoasNa+gFWoNuQMKwpDePkJQ94FpZvPYL11tSWAfTi0OzQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Aug 13, 2017 at 11:20 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-08-15 13:40:27 Re: scan on inheritance parent with no children in current session
Previous Message Robert Haas 2017-08-15 13:32:55 Re: shared memory based stat collector (was: Sharing record typmods between backends)