On Wed, Dec 17, 2003 at 10:30:23PM +0100, Martin v. L?wis wrote: > Luke Kenneth Casson Leighton <lkcl at lkcl.net> writes: > > > all i can do is recommend a framework and some guidelines on what > > conventions could be fitted over that framework. > martin, to clarify: "all i can do" is the wrong preamble phrase. "i would like to" is better. i was trying to be ... self-denigrating, over-careful, something like that. > originally provided. To prove that, I would need a complete proposal > how precisely what ACLs are set on what objects, and how exactly I > invoke code for restricted execution (i.e. what API do I call in what > order). what api, in what order, what code is invoked in (inside the python executable), _how_ ACLs are set on what objects, yes. _what_ acls are set on what objects is conditional on whether i receive funding to do so, or whether some other people can be of significant assistance. why? because there's a lot of them. what i was trying to say above, "all i can do is recommend a framework" is build up to an idea of adding in a framework, similar to Exceptions, by which ANY generically-defined restriction system can be plugged in to the python language. the idea being that if no such a system is not plugged in, the performance penalty on python is insignificant, and no user-code is restricted. however, this may all turn out to be unnecessary [quote from greg ewing]: > The spirit behind my suggestion was to start thinking about > ways in which functionality could be separated out so that > this kind of special-casing for security purposes isn't > needed. so, with the correct codebase reordering, a simple capabilities based system can be added, the problem goes away. yes? l.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4