On Dec 20, 2007 6:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Merlin Moncure" <mmoncure@gmail.com> writes:
> > I don't really agree that wrapping pl/pgsql with encryptor/decryptor
> > is a bad idea.
>
> So if you want something other than endless arguments to happen,
> come up with a nice key-management design for encrypted function
> bodies.
Maybe a key management solution isn't required. If, instead of
strictly wrapping a language with an encryption layer, we provide
hooks (actors) that have the ability to operate on the function body
when it arrives and leaves pg_proc, we may sidestep the key problem
(leaving it to the user) and open up the doors to new functionality at
the same time.
The actor is basically a callback taking the function source code (as
text) and returning text for storage in pg_proc. Perhaps some other
house keeping variables such as function name, etc. are passed to the
actor as parameters as well. The actor operates on the function body
going into pg_proc (input actors) and going out (output actors). In
either case, the function 'body' is modified if necessary, and may
raise an error.
The validator can be considered an actor that doesn't modify the body.
Ideally, the actors can be written in any pl language. Naturally,
dealing with actors is for the superuser. So, I'm suggesting to
extend the validator concept, opening it up to the user, giving it
more power, and the ability to operate in both directions. The actor
will feel a lot like a trigger function.
Now, everything is left to the user...by adding an 'encryption' actor
to the language (trivial with pg_crypto), the user can broadly encrypt
in a manner of their choosing. A clever user might write an actor to
encrypt a subset of functions in a language, or register the same
language twice with different actors. Since the actor can call out to
other functions, we don't limit to a particular key management
strategy.
Another nice thing is we may solve a problem that's been bothering me
for years, namely that 'CREATE FUNCTION' takes a string literal and
not a string returning expression. This is pretty limiting...there
are a broad range of reasons why I might want to modify the code
before it hits pg_proc. For example, with an actor I can now feed the
data into the C preprocessor without giving up the ability of pasting
the function body directly into psql.
This isn't a fully developed idea, and I'm glossing over several areas
(for example, syntax to modify actors), and I'm not sure if it's a
good idea in principle...I might be missing an obvious reason why this
won't work. OTOH, it seems like a really neat way to introduce
encryption.
comments? is it worth going down this road?
merlin
