On Wed, Jan 25, 2017 at 11:30 AM, Greg Stark <st...@mit.edu> wrote: > I tend to agree. But in the past when this came up people pointed out > you could equally do things this way and still grant all the access > you wanted using SECURITY DEFINER. Arguably that's a better approach > because then instead of auditing the entire monitor script you only > need to audit this one wrapper function, pg_ls_monitor_dir() which > just calls pg_ls_dir() on this one directory.
I agree that can be done, but it's nicer if you can use the same SQL all the time. With that solution, you need one SQL query to run when you've got superuser privileges and a different SQL query to run when you are running without superuser privileges but somebody's run the create-security-definer-wrappers-for-me script. That's a deployment nuisance if you want to support both configurations. Also, the same argument could be made about removing the built-in superuser check from ANY function, and we've already rejected that argument for a bunch of other functions. If we say that argument is valid for some functions but not others, then we've got to decide for which ones it's valid and for which ones it isn't, and consensus will not be forthcoming. I take the position that hard-coded superuser checks stink in general, and I'm grateful to Stephen for his work making dump/restore work properly on system catalog permissions so that we can support better alternatives. I'm not asking for anything more than that we apply that same policy here as we have in other cases. -- 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
