On Fri, Jan 27, 2017 at 9:42 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers