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

Hi,

On 2017-01-25 16:52:38 -0500, Stephen Frost wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> > Preventing people from calling functions by denying the ability to
> > meaningfully GRANT EXECUTE on those functions doesn't actually stop
> > them from delegating those functions to non-superusers. It either (a)
> > causes them to give superuser privileges to accounts that otherwise
> > would have had lesser privileges or (b) forces them to use wrapper
> > functions to grant access rather than doing it directly or (c) some
> > other dirty hack. If they pick (a), security is worse; if they pick
> > (b) or (c), you haven't prevented them from doing what they wanted to
> > do anyway. You've just made it annoying and inconvenient.
>
> The notion that security is 'worse' under (a) is flawed- it's no
> different.

Huh? Obviously that's nonesense, given the pg_ls_dir example.

> With regard to 'b', if their wrapper function is
> sufficiently careful to ensure that the caller isn't able to do anything
> which would increase the caller's level to that of superuser, then
> security is improved.

Given how complex "sufficiently careful" is for security definer UDFs,
in comparison to estimating the security of granting to a function like
pg_ls_dir (or pretty much any other that doesn't call out to SQL level
stuff like operators, output functions, etc), I don't understand this.

> If the wrapper simply turns around can calls the underlying function,
> then it's no different from '(a)'.

Except for stuff like search path.

> I am suggesting that we shouldn't make it look like there are
> distinctions when there is actually no difference. That is a good thing
> for our users because it keeps them informed about what they're actually
> doing when they grant access.

This position doesn't make a lick of sense to me. There's simply no
benefit at all in requiring to create wrapper functions, over allowing
to grant to non-superuser. Both is possible, secdef is a lot harder to
get right. And you already heavily started down the path of removing
superuser() type checks - you're just arguing to make it more or less
randomly less consistent.

> I've commented on here and spoken numerous times about exactly that goal
> of reducing the checks in check_postgres.pl which require superuser.
> You're not actually doing that and nothing you've outlined in here so
> far makes me believe you see how having pg_write_file() access is
> equivilant to giving someone superuser, and that concerns me.

That's the users responsibility, and Robert didnt' really suggest
granting pg_write_file() permissions, so this seems to be a straw man.

Andres