On Wed, Jan 25, 2017 at 11:30 AM, Greg Stark <stark@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
