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
