* 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: http://www.postgresql.org/docs/9.0/static/sql-createlanguage.html TRUSTED 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". Thanks, Stephen
signature.asc
Description: Digital signature
