Luke writes: > i think the only really sensible way forward is to begin from a > sound basis... I agree completely. > proposal: how about building ACLs into the python codebase? Actually, I rather prefer the approach that has been mentioned before of trying to use capabilities. See, for instance, the threads on Capabilities found here: http://mail.python.org/pipermail/python-dev/2003-March/thread.html#33854 Of course, that's not trivial to add either, since some way would need to be provided for disabling Python's powerful introspection. > the algorithm for evaluating an acl has been worked out already, > and implemented originally by matthew chapman of the samba team, > so code under the GPL already exists [in an NT-like environment which > is over-the-top]. Unfortunately, code under the GPL is of no use at all for Python which is released with a more flexible (but GPL compatible) liscense. And I'm not quite sure what you mean by an "NT-like environment" being "over-the-top". > an empty acl also means that there is no performance penalty for having > acl code in the python codebase. Sorry, but I simply don't believe this. Really. Think about it a bit, and if you still think you're right, I'll provide some reasons, but I suspect you'll realize that it's simply not true. I *DO* think though, that some amount of slow-down *IS* acceptable (pie or no pie <wink>) if it provided powerful new capabilities like *reliable* restricted execution environments. -- Michael Chermside
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