Tom Lane wrote:
AFAICS the DBA has to participate in setting up that module, so it's
no different from any other PL language. You can insert stuff into the
trusted interpreter in pltcl too. It's on the DBA's head to not insert
stuff that's insecure --- so what? To my mind it's a feature not a
bug that this is possible. It's just like the on_init work that you've
been doing; it's about letting the DBA have control over what users of
the trusted language can get at.
Fair enough, but I think we need to be clearer in the docs about what
"trusted" actually means.
The docs say:
TRUSTED specifies that the language is safe, that is, it does not
offer an unprivileged user any functionality to bypass access
restrictions.
Perhaps we need to add some words to that to indicate that the DBA can
inject extra functionality into some trusted PLs, which might or might
not be able to access system resources.
What bothers me more is the fact that genuine holes are beginning to
show up in Safe. I wonder if we aren't seeing the first stages of what
happened to trusted plpython. Building a secure sandbox feature into
a language that wasn't designed for it is hard. However, I'm not going
to panic until there's reason for panic, and this doesn't look like a
reason.
Yes, Tim was saying something about how Safe was a failed experiment to
me the other day. I suspect we might be fairly close to having to do
something radical about that.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
