Also pfree() them when they are used. We're probably leaking a lot of
memory in the parser anyway, but since we want to NULL these for the
next round around this seems like the right thing to do.
When parsing key provider options. This was only ever really -1, 0 or 1
and the parser is easier to understand if these are just modelled with
the parser's semantic state instead.
Since ALTER TABLE can modify multiple due to inheritance or typed tables
which can for example result in TOAST tables being created for some or all
of the modified tables while the event trigger is only fired once we cannot
rely on the event stack to make sure we get the correct encryption status.
Our solution is to be cautious and only modify tables when all tables
with storage are either encrypt or not encrypted. If there is a mix we
will throw an error. The result of this is also used to properly inform
the SMGR of the current encryption status. We apply the same logic to
ALTER TYPE for typed tables.
A possibility for future improvement would be to limit this check only
to commands which recurse down to child tables and/or can create new
relfilenodes.
Rename JK_REMOTE_URL to be clearer that it belongs with JK_FIELD_TYPE
and JK_FIELD_PATH.
Rename JF_FILE_PATH which I assume was named "JF" instead of "JK" as a
typo.
Also add a couple of helpful comments.
The hint added nothing and while we could hint about what function they
should use to create a key provider this error happens also when
alternating or deleting an existing key provider making any hint pretty
much useless.
This field in the JSON was not used by anything, it wasn't even verified
to match the actual key provider type so the risk of weird data was
unnecessary.
The naming was quite inconsistent and, in the case of ECB vs CTR,
misleading. So let's make it more consistent plus remove the legacy
macros for the WAL encryption which were only used to slightly improve
debug logging.
Also do not supply any IV to ECB since it does not use any IV.
This fixes a bug when pg_tde_verify_server_key() was broken if the
server key was rotated in the same server lifetime as it was originally
created since we wrote to the cache when we created to key the first
time but not when we rotated it.
An alternative would be to fix that bug and never cache the server key
but by always caching it like we do with all other keys, including the
default key, we simplify the code paths and make this kind of bug less
likely in the future.
This also discovered a previously harmless mistake where we grabbed the
wrong lock level when trying to write a new WAL key.
An alternative would be to always call it before we use AES but having
the SMGR call initialize when the WAL SMGR and the tdemap code do not is
confusing for the user.
These functions did never really do anything since they added no extra
permissions since you would need to be allowed to grant and revoke
access anyway to call them since they did not use SECURITY DEFINER.
Do not try to decrypt data not actually read by returning directly if we
reached the end of file or got an error. If we get a short read we also
return directly which is safe snice pg_tde_crypt() supports any offset,
not just multiples of the AES block size. This likely makes it a bit
trickier to move to OpenSSL's built-in CTR which we probably want to do
in the future but let's cross that bridge when we get to it.
The pg_tde_extension_initialize() function remained after CREATE
EXTENSION and was executable by any user allowing any use to delete all
keys and break the server. This function is so dangerous that we should
not leave it around at all and instead drop it after having used it.
After the removal of tde_heap_basic we almost never encrypt short pieces
data. That only happens we decrypt WAL after or before a key switch. It
makes no sense to have extra code to optimize for such a rare and
non-performance critical case.
We get random timeouts from pg_ctl in the coverage build only so let's
increase the timeout from 60 to 120 seconds. These timeouts might
indicate that we have some issue with recovery being too slow in general
but for now let's just increase the timeout to avoid random test
failures.
When creating a key provider you can point its configuration towards any
path or network address that PostgreSQL can reach which can be used to
attack the environment of PostgreSQL in way normally only restricted to
superusers (comapre trusted vs untrusted languages). So make the
administration of key providers also follow this convention.
This limits the powers of our multitenancy but since we are not sure yet
about how users want to use our mutlitenancy it is better to start off
restrictive and build a complex solution later.
When creating a table with a serial/identity column the sequence will
get the same encryption status as the owning table but when doing the
same using CREATE SEQUENCE and ALTER SEQUENCE the sequence ended up not
encrypted so this add support for those.
A design choice is that sequences not owned by any table are never
encrypted which is unclear if it is a good choice or not.
Andreas Karlsson