From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Hiding a GUC from SQL |
Date: | 2020-06-18 14:47:43 |
Message-ID: | 402717b9aa9ef43ac6f3ebd57253317542f8b513.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2020-06-18 14:50:45 | Re: autovacuum failing on pg_largeobject and disk usage of the pg_largeobject growing unchecked |
Previous Message | Laurenz Albe | 2020-06-18 14:40:41 | Re: Conflict with recovery on PG version 11.6 |