Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check
Date
Msg-id 29446.1485527744@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Brad DeJong
Date:
Subject: Re: [HACKERS] GSoC 2017
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check