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: http://www.postgresql.org/mailpref/pgsql-hackers