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
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 |