On Wed, 2020-06-17 at 13:23 -0700, Michel Pelletier wrote: > In my extension pgsodium I'm defining a custom variable at startup to store a > key: > > https://github.com/michelp/pgsodium/blob/master/src/pgsodium.c#L1107 > > I'm using the flags GUC_NO_SHOW_ALL | GUC_NO_RESET_ALL | GUC_NOT_IN_SAMPLE | > GUC_DISALLOW_IN_FILE, > and a custom "no show" show hook that obscures the value. This idea was > inspired from the > pgcryptokey module from Bruce Momjian. > > The value cannot be shown either with SHOW or current_setting() and it does > not appear in pg_settings. > From what I can tell, the value is inaccessible from SQL, but I think it's > worth asking > the experts if there is some other demonstrable way, from SQL, that this > value could be > leaked even to a superuser. no sql level user should be able to see this > value, only a C function, > like the pgsodium_derive() from which to derive other keys, should be able to > see it. > I realize that someone with external process access can get the key, my goal > is to prevent > accessing it from SQL. > > Any thoughts on weaknesses to this approach would be welcome. Thanks! > > -Michel
A superuser can access files and start programs on the server machine. A dedicated superuser may for example attach to PostgreSQL with a debugger and read the value of the variable. And if that doesn't work, there may be other things to try. It is mostly useless to try to keep a superuser from doing anything that the "postgres" operating system user can do. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
