What are your ideas of applying a change similar to above to actually
being a superuser ?
That is adding a check for "superuser being currently available" to
function superuser() in
./src/backend/utils/misc/superuser.c ?
It could be as simple as a flag that can be set only at startup for
maximum speed - though the places needing superuser check are never in
speed-critical path as far as I have seen.
Or it could be more complex and dynamix, like having a file similar to
pg_hba.conf that defines the ability to run code as superuser based on
a set of attributes each of which could be * meaning "any"
These could be
* database (to limit superuser to only certain databases)
* session user (to allow only some users to become superuser,
including via SECURITY DEFINER functions)
* backend pid (this would allow kind of 2-factor authentication -
connect, then use that session's pid to add a row to
pg_ok_to_be_sup.conf file, then continue with your superuser-y stuff)
* valid-until - this lets one allow superuser for a limited period
without fear of forgetting top disable it
This approach would have the the benefit of being very low-code while
delivering the extra protection of needing pre-existing access to
filesystem to enable/disable .
For easiest usability the pg_ok_to_be_sup.conf file should be outside
pg_reload_conf() - either just read each time the superuser() check is
run, or watched via inotify and reloaded each time it changes.
Cheers,
Hannu
P.S: - thanks Magnus for the "please don't top-post" notice - I also
need to remember to check if all the quoted mail history is left in
when I just write a replay without touching any of it. I hope it does
the right thing and leaves it out, but it just might unders some
conditions bluntly append it anyway just in case :)