Re: system administration functions with hardcoded superuser checks

On Wed, Dec 19, 2012 at 1:58 AM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
> On 18.12.2012 18:38, Pavel Stehule wrote:
>> 2012/12/18 Peter Eisentraut <peter_e(at)gmx(dot)net>:
>>> There are some system administration functions that have hardcoded
>>> superuser checks, specifically:
>>>
>>> pg_reload_conf
>>> pg_rotate_logfile
>>>
>>> Some of these are useful in monitoring or maintenance tools, and the
>>> hardcoded superuser checks require that these tools run with maximum
>>> privileges. Couldn't we just install these functions without default
>>> privileges and allow users to grant privileges as necessary?
>>
>> isn't it too strong gun for some people ???
>>
>> I believe so some one can decrease necessary rights and it opens doors
>> to system.
>
> No one was speaking about making them executable by a wider group of
> users by default (i.e. decreasing necessary rights). Today, when you
> need to provide the EXECUTE privilege on those functions, you have three
> options

Given how limited these functions are in scope, I don't see a problem here.

>>> pg_read_file
>>> pg_read_file_all
>>> pg_read_binary_file
>>> pg_read_binary_file_all
>>> pg_stat_file
>>> pg_ls_dir
>>
>> is relative dangerous and I am not for opening these functions.
>>
>> power user can simply to write extension, but he knows what he does/
>
> I see only dangers that are already present.

Granting executability on pg_read_xyz is pretty darn close to granting
superuser, without explicitly asking for it. Well, you get "read only
superuser". If we want to make that step as easy as just GRANT, we
really need to write some *very* strong warnings in the documentation
so that people realize this. I doubt most people will realize it
unless we do that (and those who don't read the docs, whch is probably
a majority, never will).

If you use SECURITY DEFINER, you can limit the functions to *the
specific files that you want to grant read on*. Which makes it
possible to actually make it secure. E.g. you *don't* have to give
full read to your entire database.

If you're comparing it to a blanket SECURITY DEFINER with no checks,
then yes, it's a simpler way to fire the cannon into your own foot,
yes. But if also gives you a way that makes it more likely that you
don't *realize* that you're about to fire a cannon into your foot.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/