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

On Fri, Jan 27, 2017 at 9:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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.
>
> I'm not aware that they're likely to crash the server, and if they
> are, so would any regular access to the page in question. The
> things we were worried about were more along the lines of unexpected
> information disclosure.
>
> This is not to say that I'm against making those functions more
> bulletproof. I'm just saying that I find little point in reducing
> their superuser checks if we can't get rid of the one in get_raw_page.

OK, fair enough. get_raw_page() is clearly not something that we
really want everybody to have access to by default, but if it were up
to me, I'd change the permissions check inside the function to do a
check for select privileges on the relation, and then I'd change the
SQL script to revoke access from everybody but the superuser. That
way, by default, only superusers could use the function, but if they
wanted to grant access to others, they could do so. However, even
with an access grant, people could only read raw pages from relations
from which they can read data in general.

Actually, I think that's Stephen should have done something similar
for pgstattuple in commit fd321a1dfd64d30bf1652ea6b39b654304f68ae4,
and I think we should go back and fix it that way before that code
lands in a released branch. As I mentioned upthread, a user could run
that even on sensitive tables like pg_authid. That doesn't directly
reveal any data, but it does let you take a lock on a table which you
otherwise couldn't lock, and it reveals at least some information
about the contents of the table. If you ran it just before and after
an insert or update, you might be able to infer the length of the new
tuple. That's probably not enough to give you a whole lotta help
guessing what password that tuple contains ... but it's more than no
information. More fundamentally, I think it's entirely reasonable for
the superuser to be able to decide who can and can't run the
pgstattuple functions, but I strongly suspect that very few superusers
would want to give users rights to run those functions on tables to
which those users otherwise have no access.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company