* David Fetter (david@fetter.org) wrote:
> I have been looking for a document which specifies what trusted and
> untrusted PLs must do and forbid, so far without result.
I think you might have been missing the tree for the forest in this
case.. :) I'm sure you've seen this, but perhaps you weren't thinking
about how broad it really is:
http://www.postgresql.org/docs/9.0/static/sql-createlanguage.html
TRUSTED
TRUSTED specifies that the language is safe, that is, it does notoffer an unprivileged user any functionality to
bypassaccessrestrictions. If this key word is omitted when registering thelanguage, only users with the PostgreSQL
superuserprivilege can usethis language to create new functions.
That's about it- a language is TRUSTED if there's no way for a user to
be able to write a function which will give them access to things
they're not supposed to have. Practically, this includes things like
any kind of direct I/O (files, network, etc).
> Where do we document this, and if we don't where *should* we document
> this?
I'd be hesitant about trying to document exactly what a PL must do to be
trusted at a more granular level than what's above- mostly because, if
we change some functionality, we would end up having to document that
change in the place which is appropriate for it and then also in the
list of "things trusted PLs shouldn't do/allow".
Thanks,
Stephen