On Fri, Jan 27, 2017 at 9:35 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> - contrib/pageinspect has lots of superuser checks, basically because
>> they have known input-validation weaknesses.  See
>> 3e1338475ffc2eac25de60a9de9ce689b763aced for the rationale in detail.
> FWIW, I think that's a bit of an oversimplification.  There are two
> components to contrib/pageinspect: get_raw_page() and a pile of page
> interpretation functions.  The input-validation issue appies primarily
> to the interpretation functions.
> In principle, if we could make the interpretation functions completely
> bulletproof, we could remove all security checks for them.  However,
> they're largely useless without get_raw_page(), so it's not apparent
> what's the point of doing a lot of work (and taking the risk of missing
> something) unless we first get rid of get_raw_page()'s superuser check.
> And that seems fraught with questions.  Maybe it'd be all right to
> allow it for tables you have full read access to (can select all columns,
> no RLS) but I'm not convinced.  For example, full read access doesn't
> allow you to see values that were in the table in the past, before you
> were granted read access ... but get_raw_page() might.

The problem is if the interpretation functions aren't completely
bulletproof, they might do things like crash the server if you use
them to read a corrupt page.  That is not any more appealing if you
happen to be running as superuser() than otherwise.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to