Specification for Trusted PLs?
in [PgSql]
|
From: Stephen Frost on 21 May 2010 08:40 * David Fetter (david(a)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
From: Peter Geoghegan on 21 May 2010 08:55 > 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). The fact that plpythonu used to be plpython back in 7.3 serves to illustrate that the distinction is not all that well defined. I guess that someone made an executive decision that the python restricted execution environment wasn't restricted enough. Regards, Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 21 May 2010 09:04 Peter Geoghegan <peter.geoghegan86(a)gmail.com> writes: >> 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). > The fact that plpythonu used to be plpython back in 7.3 serves to > illustrate that the distinction is not all that well defined. I guess > that someone made an executive decision that the python restricted > execution environment wasn't restricted enough. Well, it was the upstream authors of python's restricted execution environment who decided it was unfixably insecure, not us. So the "trusted" version had to go away. (For awhile there last month, it was looking like plperl was going to suffer the same fate :-(. Fortunately Tim Bunce thought of a way to not have to rely on Safe.pm anymore.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 21 May 2010 11:55 So, here's a working definition: 1) cannot directly read or write files on the server. 2) cannot bind network ports 3) uses only the SPI interface to interact with postgresql tables etc. 4) does any logging only using elog to the postgres log Questions: a) it seems like there should be some kind of restriction on access to memory, but I'm not clear on how that would be defined. b) where are we with the whole trusted module thing? Like for CPAN modules etc. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 21 May 2010 11:57
On Fri, May 21, 2010 at 11:55 AM, Josh Berkus <josh(a)agliodbs.com> wrote: > So, here's a working definition: > > 1) cannot directly read or write files on the server. > 2) cannot bind network ports To make that more covering, don't yu really need something like "cannot communicate with outside processes"? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |