On Fri, Jan 27, 2017 at 9:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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