Re: pg_ls_dir & friends still have a hard-coded superuser check

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_ls_dir & friends still have a hard-coded superuser check
Date: 2017-01-27 14:35:44
Message-ID: 29446.1485527744@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-01-27 14:36:01 Re: pg_ls_dir & friends still have a hard-coded superuser check
Previous Message Brad DeJong 2017-01-27 14:17:10 Re: GSoC 2017