Re: Hiding a GUC from SQL

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

In response to

Responses

Browse pgsql-general by date

  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