* David Fetter (da...@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:



    TRUSTED specifies that the language is safe, that is, it does not
        offer an unprivileged user any functionality to bypass access
        restrictions. If this key word is omitted when registering the
        language, only users with the PostgreSQL superuser privilege can use
        this 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".



Attachment: signature.asc
Description: Digital signature

Reply via email to