From: | Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> |
---|---|
To: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Hiding a GUC from SQL |
Date: | 2020-06-17 20:23:19 |
Message-ID: | CACxu=vJhoXdtMKJR+Pc0T=4UknLYUKQzKJhwwBnJbemQwN1d0w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-06-17 22:55:25 | Re: Hiding a GUC from SQL |
Previous Message | Tom Lane | 2020-06-17 18:37:12 | Re: autovacuum failing on pg_largeobject and disk usage of the pg_largeobject growing unchecked |