From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_ls_dir & friends still have a hard-coded superuser check |
Date: | 2017-01-25 19:09:40 |
Message-ID: | 20170125190940.GM9812@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg,
* Greg Stark (stark(at)mit(dot)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'm not a fan of SECURITY DEFINER functions for this sort of thing and
don't like the suggestion of simply wrapping functions that provide
superuser-level access in a security definer function and then saying
that giving someone access to that function isn't giving them superuser,
because that's just false.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-01-25 19:13:45 | Re: pg_ls_dir & friends still have a hard-coded superuser check |
Previous Message | Stephen Frost | 2017-01-25 19:08:34 | Re: pg_ls_dir & friends still have a hard-coded superuser check |