Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
Brett Cannon wrote: On 7/5/06, Talin [EMAIL PROTECTED] wrote: Transitioning from the checked to the unchecked state could only be done via C code. So the 'file' wrapper, for example, would switch over to the unchecked interpreter before calling the actual methods of 'file'. That C wrapper might also check the current permission state to see what operations were legal. So add the proper checks in Python/ceval.c:call_function() to check for this flag on every object passed in that is called? Right. I also realized that you would need to add code that propagates the checked bit from the class to any instances of the class. So whenever you call a class to create an object, if the class has the checked bit, the instance will have it set as well. So essentially, what I propose is to define a simple security primitive - which essentially comes down to checking a single bit - and use that as a basis to create more complex and subtle security mechanisms. Right, but it does require that the proper verification function be turned on so that the permission bit on 'file' is checked. It kind of seems like 'rexec' and its f_restricted flag it set on execution frames, except you are adding an object-level flag as well. Either way, the trick is not fouling up switching between the two checking functions. -Brett I wasn't aware of how rexec worked, but that seems correct to me. Given a 'restricted' flag on a stack frame, and one on the object as well, then the code for checking for permission violations is nothing more than: if (object.restricted exec_frame.restricted) raise SecurityException In particular, there's no need to call a function to check a permission level or access rights or anything of the sort - all that stuff is implemented at a higher level. By making the check very simple, it can also be made very fast. And by making it fast, we can afford to call it a lot - for every operation in fact. And if we can call it for every operation, then we don't have to spend time hunting down all of the possible loopholes and ways in which 'file' or other restricted objects might be accessed. Originally I had thought to simply add a check like the above into the interpreter. However, that would mean that *all* code, whether restricted or not, would have to pay the (slight) performance penalty of checking that flag. So instead, I thought it might be more efficient to have two different code paths, one with the check and one without. But all this is based on profound ignorance of the interpreter - there might be a hundred other, better ways to do this without having to create two versions of ceval. Another interesting think about the check bit idea is that you can set it on any kind of object. For example, you could set it on individual methods of a class rather than the class as a whole. However, that's probably needlessly elaborate, since fine-grained access control will be much more elegantly achieved via trusted wrappers. -- Talin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
Brett Cannon wrote: On 7/5/06, *Greg Ewing* [EMAIL PROTECTED] And I would change file() so that it didn't open files. Then it would be harmless for code to have access to the file class. Right, that is essentially what I proposed initially with the whole crippling idea. What the capabilities supporters are saying is that if we go that route we will be constantly finding objects that require similar crippling. We've got our wires crossed somewhere. I *am* a capabilities supporter. But for a capability model to work, the capabilities need to be isolated and encapsulated in functions or objects that can be independently provided or not provided. In the case of file(), that means separating the capability of being able to open a file from the capability of accessing an already-opened file. These two things are currently conflated in the file class. BTW, I object to the term crippling in this particular case. If you have access to open(), there's no need for file() to be able to do the same thing. And if you don't have access to open(), it's because someone doesn't want you to be able to open files. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch and static, redux
Guido van Rossum [EMAIL PROTECTED] wrote: So, my proposal is to give up on static, accept PEP 3103 with the following options: - Syntax alternative 2+B (unindented cases, 'case in ...' for multiple cases). - Semantics option 3 (def-time freezing) I know it's only a bikeshed issue here, but wouldn't it be the first case where a statement ending with : does not introduce an indented suite? Is it really worth to create this non-orthogonality in the language? IMHO, if we went for indentend cases, we could teach editors to indent cases *only* 1 or 2 spaces. That would preserve orthogonality of the language, and allow not to consume too much horizontal space. Or, what about optionally indented cases? That is, allow both forms as correct syntax. It would make it just a matter of style at that point (and Python will finally have its first religious wars over indentation AT LAST! :) Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
Another thing I perhaps should point out is that I'm proposing the separation of open() and file() for *all* code, not just restricted code. So it's not a matter of crippling file() specially for restricted code. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
Evan Simpson wrote: I'd like to toss one more variant into the mix. If we really need to address variables in an intermediate scope, the most explicit way that I can think of doing so is to write (using Philip's example): def counter(num): scope as outer # outer is an arbitrary identifier def inc(): outer.num += 1 return outer.num return inc This is somewhat similar to the unworkable use the function name method that's been suggested. The scope as X statement associates the name X with the namespace of local variables in the scope in which it is executed. Such names are lexically scoped, and only allow access to or rebinding of existing names from the originating scope (i.e. no del outer.num allowed). Why couldn't at least augmented assignment be implicitly rebinding? It has been suggested before (in the context of a rebinding operator), but I'm wondering, is this also off the table? def counter(num): def inc(): num += 1 return num return inc Reads very natural to me. It's likely the most frequent example of what people try before they learn that rebinding to outer scopes isn't allowed. It could Just Work. Just ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
[EMAIL PROTECTED] wrote: jan-python So.. are we only thinking about implementing this outer jan-python scope assignment because there's lots of talk about it on jan-python the list, ... :-) jan-python ... or are there actually use cases that would become jan-python clearer if assigning to an outer scope variable was allowed? I think full lexical scoping will only be of use to people who use nested scopes heavily. The more typical user will be happy to just refer to values in outser scopes without modifying them and rely on classes to save changed state across calls. I think it's almost a YAGNI, but I'm sure others will disagree. I think it falls into the same category as Guido's ultimate acceptance of PEP 308. There are assorted ways to live *without* conditional expressions, but each of the workarounds for its absence had issues. Switching to a statement worked properly, but meant you didn't have a single expression any more. Use the and-or trick kept the single expression characteristic, but was easy to get wrong. Hence, PEP 308: One Obvious Way to do it, assuming you want to do it in the first place. I think writing to outer scopes is similar. You can box the variable, or make it an attribute of an object, but either approach requires you to refactor *all* uses of the variable, rather than just the one you currently care about. Hence, 'nonlocal': One Obvious Way to do it, assuming you want to do it in the first place. That way, when you're *reading* the code of someone who likes to use such tricks, you only need to know how to read the one obvious way, rather than having to decipher whichever method they've chosen to work around the limitation. The perennial accumulator example still takes 6 lines, though: def accumulator(n): def increment(i): nonlocal n n += i return n return increment Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
Just van Rossum wrote: Why couldn't at least augmented assignment be implicitly rebinding? It has been suggested before (in the context of a rebinding operator), but I'm wondering, is this also off the table? def counter(num): def inc(): num += 1 return num return inc Reads very natural to me. It's likely the most frequent example of what people try before they learn that rebinding to outer scopes isn't allowed. It could Just Work. note that most examples of this type already work, if the target type is mutable, and implement the right operations: def counter(num): num = mutable_int(num) def inc(): num += 1 return num return inc maybe we should consider adding mutable strings and mutable numbers to Python 3.0 ? and a mutable built-in, that does the opposite of the freeze stuff: def counter(num): num = mutable(num) def inc(): num += 1 return num return inc (what is this thread doing on python-dev, btw? shouldn't it be over at the 3000 list, so I can enjoy my vacation without being drawn into yet another endless discussion thread ;-) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
Greg Ewing wrote: Another thing I perhaps should point out is that I'm proposing the separation of open() and file() for *all* code, not just restricted code. So it's not a matter of crippling file() specially for restricted code. What would the signature of the file constructor be in that case? Would it accept a single CObject instance, with open() bypassing the normal constructor, and handing the file pointer directly to the file object instance? It seems like a reasonable approach for making 'dangerous' objects like file and socket much easier to secure - have a separate factory function to create *new* instances at the C level, so that you can hand the objects over without worrying about providing access to the constructor (because the constructor *accepts* the OS-level object as an argument, rather than creating it anew). Alternatively, using a no-Python-level-introspection metaclass might be another way to achieve the same effect in a more universal fashion. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] SVN write access is back
I just turned the subversion write access back on. Unfortunately, I did not manage to perform the changes I wanted (import ctypes), so I'll have to retry later when the open issues have been clarified. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_ctypes failure on Mac OS X/PowerPC 10.3.9 (Panther)
Ronald Oussoren schrieb: On 20-jun-2006, at 20:50, Ronald Oussoren wrote: On 20-jun-2006, at 20:06, Thomas Heller wrote: Trent Mick schrieb: Thomas and others, Has anyone else seen failures in test_ctypes on older Mac OS X/ PowerPC? Results are below. This is running a build of the trunk from last night: ./configure make ./python.exe Lib/test/test_ctypes.py Note that the test does NOT fail on the Mac OS X/x86 10.4.6 box that I have. It also works on 10.4.?? Power PC. I guess the fix has to wait until I'm able to install 10.3 on my mac, I have the DVDs already but have not yet had the time. If anyone is willing to give me ssh access to a 10.3 box I can try to fix this earlier. I had some problems with my 10.3-capable box, but happily enough it decided to come alive again. I'm currently booted into 10.3.9 and will have a look. It is a platform bug, RTLD_LOCAL doesn't work on 10.3. The following C snippet fails with the same error as ctypes: FAIL: dlcompat: unable to open this file with RTLD_LOCAL. This seems to be confirmed by this sourcet test file from darwin: http://darwinsource.opendarwin.org/ 10.4.1/dyld-43/unit-tests/test-cases/dlopen-RTLD_LOCAL/main.c. I think that this problem still exists. From what I have found out so far (still I don't have access to osx 10.3 myself), it seems that there are three possibilities: - ignore this issue ;-) - make RTLD_GLOBAL the default mode on osx: either on 10.3 only, or on all versions (how can I determine 10.3 from 10.4?) - change the *test* only so that RTLD_GLOBAL is used on osx. I do not know how other ctypes users on osx are affected by this problem, however http://codespeak.net/pypy/dist/pypy/doc/rctypes.html#ctypes-version-and-platform-notes recommends to patch ctypes/__init__.py on osx 10.3. Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extended Subversion outage: Friday 16:40 GMT
Martin v. Löwis wrote: I plan to do some subversion administration tomorrow; in order to be able to roll back changes, I have to disable write access during these changes. I'm going to make a second attempt ten minutes from now. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extended Subversion outage: Friday 16:40 GMT
Martin v. Löwis wrote: Martin v. Löwis wrote: I plan to do some subversion administration tomorrow; in order to be able to roll back changes, I have to disable write access during these changes. I'm going to make a second attempt ten minutes from now. I completed importing the ctypes history, so the repository is now back online. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
On 7/6/06, Talin [EMAIL PROTECTED] wrote: Brett Cannon wrote: On 7/5/06, Talin [EMAIL PROTECTED] wrote: Transitioning from the checked to the unchecked state could only be done via C code. So the 'file' wrapper, for example, would switch over to the unchecked interpreter before calling the actual methods of 'file'. That C wrapper might also check the current permission state to see what operations were legal. So add the proper checks in Python/ceval.c:call_function() to check for this flag on every object passed in that is called?Right. I also realized that you would need to add code that propagatesthe checked bit from the class to any instances of the class. Sowhenever you call a class to create an object, if the class has the checked bit, the instance will have it set as well. So essentially, what I propose is to define a simple security primitive - which essentially comes down to checking a single bit - and use that as a basis to create more complex and subtle security mechanisms. Right, but it does require that the proper verification function be turned on so that the permission bit on 'file' is checked.It kind of seems like 'rexec' and its f_restricted flag it set on execution frames, except you are adding an object-level flag as well. Either way, the trick is not fouling up switching between the two checking functions. -BrettI wasn't aware of how rexec worked, but that seems correct to me.Given a 'restricted' flag on a stack frame, and one on the object aswell, then the code for checking for permission violations is nothing more than:if (object.restricted exec_frame.restricted)raise SecurityExceptionIn particular, there's no need to call a function to check a permissionlevel or access rights or anything of the sort - all that stuff is implemented at a higher level.By making the check very simple, it can also be made very fast. And bymaking it fast, we can afford to call it a lot - for every operation infact.And if we can call it for every operation, then we don't have to spend time hunting down all of the possible loopholes and ways in which 'file'or other restricted objects might be accessed.Not true. You have to set this object restriction flag, right? What happens if you don't set it on all of the proper classes/types? You end up in the exact same situation you are with crippling; making sure you cover your ass with what you flag as unsafe else you risk having something get passed you. Originally I had thought to simply add a check like the above into theinterpreter. However, that would mean that *all* code, whether restricted or not, would have to pay the (slight) performance penalty ofchecking that flag. So instead, I thought it might be more efficient tohave two different code paths, one with the check and one without. But all this is based on profound ignorance of the interpreter - there mightbe a hundred other, better ways to do this without having to create twoversions of ceval.Yeah, keep it simple, especially when it comes to ceval.c . Another interesting think about the check bit idea is that you can set it on any kind of object. For example, you could set it on individualmethods of a class rather than the class as a whole. However, that'sprobably needlessly elaborate, since fine-grained access control will be much more elegantly achieved via trusted wrappers.Yeah, that seems a bit extreme.-Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
Kevin Jacobs [EMAIL PROTECTED] wrote:
Why not extend the interface to the locals builtin and add a __getitem__
that returns a proxy to access locals defined in other lexical scopes
via __{get/set/del}attr_:
def counter(num):
num = 1
def inc():
locals[1].num += 1
return outer.num
return inc
Where, for CPython, locals[n] gives access to
NamespaceProxy(sys._getframe(n).f_locals).
Two nits: First, I suspect that you meant to write return
locals[1].num. Second, sys._getframe doesn't do what you want, here.
It reaches back up the call chain, not out into lexically containing scopes.
That said, I like the idea of giving locals[] the meaning you
intended. It has the advantage of not adding any new keywords or
syntactic constructs, but the disadvantage of not explicitly signaling
that locals in a given scope will be twiddled elsewhere. Also, for
efficiency's sake, it might be desirable to only allow a literal integer
as the index, and to deal with use of locals[] at compile time rather
than dynamically. I'm not sure how much overhead would be involved in
enabling dynamic lookup of arbitrary lexically containing scopes, but I
would *not* want to enable stuff like locals[i * 2 - 1].
Cheers,
Evan @ 4-am
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [slighly OT] Native speakers and hurting brains
Guido van Rossum wrote: On 7/5/06, Michael Chermside [EMAIL PROTECTED] wrote: Guido writes: [discussion of how to fix the can't-bind-outer-scope-vars wart] ... Are there any other native speakers who side with Michael? A bit OT, but why should native speakers (eg of English) have special authority ? I mean this neither as an attack on native speakers nor as a rethorical question. I recently re-read the sum() discussion to figure out how it came about that sum() half bails out on sequences_of_sequences (by requiring me to specify the start value) except when the nested sequences are strings, in which cases it 90% bails out : by first asking for an adequate start value, and *then* - once I've provided it - telling me it understands my intent but that I should use ''.join instead. Is this a programming language shell or a text-based adventure game ? 0.8 wink AFAICT, the cause of this funny strangeness is that a very respected member of pydev and native speaker of English with an truly unique sense of humor, found early in the discussion that sum(sequence_of_strings) made his brain hurt; and while this person is the very opposite of a newbie, his judgment was combined with concerns relating to newbies to result in the current behavior. I believe that in this case native linguistic intuition made the decision... and that a non-native intuition should have reversed it by noting in due time that the cognitive dissonance that native speakers could find to sum(seq_of_str), isn't in fact distinct from the cognitive dissonance that any newbie should find to the use of the + operator to concatenate strings or sequences rather than summing numbers. To restate, as a non-native speaker, and inasmuch it hurts the brain is the real reason against sum(seq_of_str) calling ''.join(seq_of_str) directly, I believe this is a case of excess authority being given to native linguistic intuition (of english speaking python experts) with the result of /adding/ to the cognitive dissonance of using + to concatenate strings (for all programming newbies). Best regards to all, Boris Borcic -- On naît tous les mètres du même monde ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
On 7/7/06, Greg Ewing [EMAIL PROTECTED] wrote: Brett Cannon wrote: On 7/5/06, *Greg Ewing* [EMAIL PROTECTED] And I would change file() so that it didn't open files. Then it would be harmless for code to have access to the file class. Right, that is essentially what I proposed initially with the whole crippling idea. What the capabilities supporters are saying is that if we go that route we will be constantly finding objects that require similar crippling.We've got our wires crossed somewhere. I *am* a capabilitiessupporter. But for a capability model to work, the capabilitiesneed to be isolated and encapsulated in functions or objects that can be independently provided or not provided. In thecase of file(), that means separating the capability ofbeing able to open a file from the capability of accessingan already-opened file. These two things are currently conflated in the file class.OK, putting that way makes sense for labelling it as capabilities support. It just seems like everyone else who has been calling for more capabilities have not been wanting to change file() in any way. BTW, I object to the term crippling in this particularcase. If you have access to open(), there's no need for file() to be able to do the same thing. And if you don'thave access to open(), it's because someone doesn't wantyou to be able to open files.But, from the perspective of what file() can do now, it is losing an ability that it once had and not quite as powerful as it was. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
On 7/7/06, Greg Ewing [EMAIL PROTECTED] wrote: Another thing I perhaps should point out is thatI'm proposing the separation of open() and file()for *all* code, not just restricted code. So it'snot a matter of crippling file() specially forrestricted code. Well, that's fine with me since I use open() for opening all of my files anyway. But I don't know if people want to make 'file' the only built-in type who lacks a constructor on the type itself. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
At 09:56 PM 7/6/2006 -0400, Kevin Jacobs [EMAIL PROTECTED] wrote:
Why not extend the interface to the locals builtin and add a __getitem__
that returns a proxy to access locals defined in other lexical scopes via
__{get/set/del}attr_:
def counter(num):
num = 1
def inc():
locals[1].num += 1
return outer.num
return inc
Where, for CPython, locals[n] gives access to
NamespaceProxy(sys._getframe(n).f_locals).
That doesn't actually work, because sys._getframe(1) will give you inc()'s
caller, *not* the frame where it was defined.
In addition to having a relatively pleasing and explicit syntax, this
may be a feasible method for allowing portable introspection into outer
scopes without having to export the whole frame object a la
sys._getframe(n). I strongly suspect that Jython, IronPython, and PyPy
would have little difficulty supporting (and optimizing) this construct.
Lacking core language support, it is easy to roll an object that does just
what I suggest. Actual implementation is left to a more motivated reader,
of course.
While I hesitate to describe anything as impossible, I will note that an
implementation with the syntax you suggest is not likely to be possible
without resorting to ctypes or a C module, because the frame doesn't have a
reference to the function, only the code object, and it's the function
objects that own the closure cells.
I think the only way you can reasonably accomplish rebinding in Python
right now is to have a rebind(func, var=value) function, e.g.:
def counter(num):
def inc():
rebind(inc, num=num+1)
return num
return inc
It doesn't allow augmented assignment, of course, and it also creates a
circular reference between 'inc' and itself, requiring garbage collection
to clean up.
Anyway, the actual implementation of such a rebind function would basically
be a bit of syntax sugar over this cookbook recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440515
You'd want to just use the keyword argument names to figure out which cells
of the function needed changing. And the whole thing would be really slow
and complex. You'd probably be better off using function attributes:
def counter(num):
def inc():
inc.num+=1
return inc.num
inc.num = num
return inc
It's not ideal, but *this* should probably be the pattern we recommend for
rebinding, rather than create a class or use an anonymous namespace
argument.
It can even be prettied up a little bit with a decorator to set the
function attributes.
def counter(num):
@uses(num=num)
def inc():
inc.num+=1
return inc.num
return inc
But that's about as good as it gets, which is nowhere near as good as:
def counter(num):
def inc():
nonlocal num
num+=1
return num
return inc
On the other hand, the rebind() syntax actually is slightly cleaner in some
respects:
def counter(num):
def inc():
rebind(num = num+1)
return num
return inc
Maybe we should just make rebind() a fast builtin. ;)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
Brett Cannon wrote: On 7/6/06, Talin [EMAIL PROTECTED] wrote: And if we can call it for every operation, then we don't have to spend time hunting down all of the possible loopholes and ways in which 'file' or other restricted objects might be accessed. Not true. You have to set this object restriction flag, right? What happens if you don't set it on all of the proper classes/types? You end up in the exact same situation you are with crippling; making sure you cover your ass with what you flag as unsafe else you risk having something get passed you. But that's a much simpler problem. With the restricted flag, it isn't just *your* code that is prevented from using 'file' - it's *all* code. Only approved gateways that remove the restriction (by setting the interpreter state) can perform operations on file objects without blowing up. This means that if you call some random library function that attempts to open a file, it won't work, because the random library function is still running in restricted mode. Similarly, if you have a reference to some externally created object that has a reference to a file (or the file class) somewhere in it's inheritance hierarchy, any attempt to access that object will fail. Without this, you would have to chase down every bit of library code that opens file, or has a reference to a file. What I am proposing shares some aspects of both the crippling and the capability model: It's similar to crippling in the sense that you're protecting the object itself, not access to the object. So you avoid the problem of trying to figure out all of the possible ways an object can be accessed. However, where it resembles capabilities is that its an 'all or nothing' approach - that is, you either have access to file, or you don't. Unlike the crippling model where fine-grained access control is implemented by modifying individual methods of the crippled object, in this scheme we cripple the object *entirely*, and then provide fine-grained access control via wrappers. Those wrappers, in turn, act just like capabilities - you can have different wrappers that have different sets of access permissions. So it provides the advantage of the capability approach in that the set of restrictions can be extended or modified by writing new wrappers. Thus, by providing an extremely simple but unbreakable check at the interpreter level, we can then write classes that build on top of that a richer and more sophisticated set of permissions, while still maintaining a strong barrier to unauthorized actions. -- Talin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
On 7/7/06, Talin [EMAIL PROTECTED] wrote: Brett Cannon wrote: On 7/6/06, Talin [EMAIL PROTECTED] wrote: And if we can call it for every operation, then we don't have to spend time hunting down all of the possible loopholes and ways in which 'file' or other restricted objects might be accessed. Not true.You have to set this object restriction flag, right?What happens if you don't set it on all of the proper classes/types?You end up in the exact same situation you are with crippling; making sure you cover your ass with what you flag asunsafe else you risk having something get passed you.But that's a much simpler problem. With the restricted flag, it isn't just *your* code that is preventedfrom using 'file' - it's *all* code. Only approved gateways that removethe restriction (by setting the interpreter state) can perform operations on file objects without blowing up.This means that if you call some random library function that attemptsto open a file, it won't work, because the random library function isstill running in restricted mode. Right, but that happens with either approach being proposed anyway. Similarly, if you have a reference to some externally created objectthat has a reference to a file (or the file class) somewhere in it'sinheritance hierarchy, any attempt to access that object will fail.Without this, you would have to chase down every bit of library code that opens file, or has a reference to a file.Not true. With the library code running under a sandboxed interpreter the checks by either implementation will still be in effect. And if a proxy is returned by open() instead of 'file' with stuff crippled then the worries alleviated even further. What I am proposing shares some aspects of both the crippling and thecapability model: It's similar to crippling in the sense that you're protecting the objectitself, not access to the object. So you avoid the problem of trying tofigure out all of the possible ways an object can be accessed. However, where it resembles capabilities is that its an 'all or nothing'approach - that is, you either have access to file, or you don't. Unlikethe crippling model where fine-grained access control is implemented by modifying individual methods of the crippled object, in this scheme wecripple the object *entirely*, and then provide fine-grained accesscontrol via wrappers. Those wrappers, in turn, act just likecapabilities - you can have different wrappers that have different sets of access permissions.So it provides the advantage of the capability approach in that the setof restrictions can be extended or modified by writing new wrappers.Thus, by providing an extremely simple but unbreakable check at the interpreter level, we can then write classes that build on top of that aricher and more sophisticated set of permissions, while stillmaintaining a strong barrier to unauthorized actions. I guess I am just not seeing where your approach is better than preventing the constructor in 'file' and having open() return the 'file' object or proxy object. With your approach 'file' would be flagged, but with the other you just put the same check in 'file's constructor. With both you would probably also want open() to be a factory function anyway. So I don't see where you gain simplicity or more security. It seems like you are pushing the check into the eval loop, but you still require the flagging of objects as unsafe. Going with the other two proposals you don't burden the eval loop with the check but the objects that you would have flagged in the first place. It just seems like we are pushing around the flagging of unsafe stuff and that doesn't feel like it buys us much.-Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Musings on concurrency and scoping (replacing Javascript)
On 7/7/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
I've been doing a bunch of Firefox extension programming in Javascript
and suddenly a few of the recent topics here came together in my head
in a silent kapow of thoughts. This is kind of a side note to the
security discussion, but they're all interconnected: network
programming, concurrency, lexical scoping, security.
Hm... I wonder if this style has become so popular in JS because it's
all they have? I find callback-style programming pretty inscrutable
pretty soon.
Client-side web scripting tends to have a callback/continuation-ish
concurrency style because it has to deal with network transactions
(which can stall for long periods of time) in a user interface that
is expected to stay always responsive. The Firefox API is full of
listeners/observers, events, and continuation-like things. So one
thing to consider is that, when Python is used for these purposes,
it may be written in a specialized style.
As i write JavaScript in this style i find i use nested functions
a lot. When i want to set up a callback that uses variables in the
current context, the natural thing to do is to define a new function
in the local namespace. And if that function has to also provide a
callback, then it has another function nested within it and so on.
function spam() {
var local_A = do_work();
do_network_transaction(
new function(result_1) {
var local_B = do_work(result_1);
do_network_transaction(
new function(result_2) {
do_work(local_A, local_B, result_1, result_2);
...
}
);
}
);
}
How can you ever keep track of when a '}' must be followed by a ';' ?
So it is a possible consequence of embedding Python in Firefox that
people will be using nested functions and lexical scoping in Python
more often, which makes the recent discussion about access to
enclosing scopes more significant.
This is even related to security as well. Namespaces and lexical
scoping are a natural and visually apparent way to limit access.
If, for example, result_1 and result_2 in the above example are
security-sensitive objects like secret keys or networking functions,
you can see just by inspection that they cannot leak outside of
spam() except by directly being passed in an outgoing function call.
The standard Pythonic response to nested functions is to translate
them into classes. But the nested function style has two advantages:
1. Variables are more appropriately scoped; they exist
only where they are meaningful. (In a class, all the
variables would be mixed into one namespace, where
some of them would be invalid some of the time.)
This doesn't strike me as very important. The same can happen in a
local scope and doesn 't seem to bother anyone there.
2. Local variables are private. (Class instances don't
get their own private namespaces to play in.)
Hmm... I wouldn't be so sure of that. Exception handlers have access
to locals of stack frames above and below the current frame.
The first becomes more significant when in a more continuation-y
style because it helps keep the various continuations from
interfering with each other. The second becomes more significant
if you care about restricting untrusted Python code.
I would rather come up with a more Pythonic style of asynchronous
event handling, e.g. based on yield as shown by Phillip.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] introducing __dir__?
+1 here too. This could be added easily to Python 2.6. --Guido On 7/7/06, Nick Coghlan [EMAIL PROTECTED] wrote: Fred L. Drake, Jr. wrote: On Thursday 06 July 2006 13:22, tomer filiba wrote: my suggestion is simple -- replace this mechanism with a __dir__ - a special method that returns the list of attributes of the object. rationale: * remove deprecated __methods__, etc. * symmetry -- just like hex() calls __hex__, etc. * __methods__ and __members__ are lists rather than callable objects, which means they cannot be updated on-demand +1 +1 here, too. It would also allow objects which override __getattribute__ and/or __getattr__ to make dir() provide a sane answer (or raise an exception to indicate that a sane answer isn't possible). (This was something that actually came up when trying to implement a namespace object that *didn't* automatically fall back to its class namespace for Python level attribute access) For backwards compatibility, dir() could still fall back to the current mechanism if __dir__ isn't found. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
On 7/7/06, Brett Cannon [EMAIL PROTECTED] wrote: I guess I am just not seeing where your approach is better than preventing the constructor in 'file' and having open() return the 'file' object or proxy object. With your approach 'file' would be flagged, but with the other you just put the same check in 'file's constructor. With both you would probably also want open() to be a factory function anyway. So I don't see where you gain simplicity or more security. It seems like you are pushing the check into the eval loop, but you still require the flagging of objects as unsafe. Going with the other two proposals you don't burden the eval loop with the check but the objects that you would have flagged in the first place. It just seems like we are pushing around the flagging of unsafe stuff and that doesn't feel like it buys us much. At the risk of repeating someone's point or making no sense (I'm only following this with half an ear) I would like to point out that as long as there's C code involved, we can have the equivalent of private constructors in C++/Java. This means classes that cannot be constructed by calling the class from Python. C code has to use some other API to create an instance, bypassing this check. It seems reasonable to me, even if most popular types *can* be constructed. There are other types that have this property, e.g. list iterators. Try type(iter(list()))(). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
On 7/7/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 7/7/06, Brett Cannon [EMAIL PROTECTED] wrote: I guess I am just not seeing where your approach is better than preventing the constructor in 'file' and having open() return the 'file' object or proxy object.With your approach 'file' would be flagged, but with the other you just put the same check in 'file's constructor.With both you would probably also want open() to be a factory function anyway.So I don't see where you gain simplicity or more security.It seems like you are pushing the check into the eval loop, but you still require the flagging of objects as unsafe.Going with the other two proposals you don't burden the eval loop with the check but the objects that you would have flagged in the first place. It just seems like we are pushing around the flagging of unsafe stuff and that doesn't feel like it buys us much. At the risk of repeating someone's point or making no sense (I'm onlyfollowing this with half an ear) I would like to point out that aslong as there's C code involved, we can have the equivalent of private constructors in C++/Java. This means classes that cannot beconstructed by calling the class from Python. C code has to use someother API to create an instance, bypassing this check. It seemsreasonable to me, even if most popular types *can* be constructed. There are other types that have this property, e.g. list iterators.Try type(iter(list()))().Good point. C code could circumvent the bit check by doing all of the work behind the scenes without pushing the object on the stack. But if the check is in the C code for the object itself it is much harder to get around. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Musings on concurrency and scoping (replacing Javascript)
On Fri, 7 Jul 2006, Guido van Rossum wrote: On 7/7/06, Ka-Ping Yee [EMAIL PROTECTED] wrote: I've been doing a bunch of Firefox extension programming in Javascript and suddenly a few of the recent topics here came together in my head in a silent kapow of thoughts. This is kind of a side note to the security discussion, but they're all interconnected: network programming, concurrency, lexical scoping, security. Hm... I wonder if this style has become so popular in JS because it's all they have? I find callback-style programming pretty inscrutable pretty soon. Yes, i would love to be able to use generators instead. Maybe this will be a strong selling point for Python when it's ready for browser scripting. (There may be a fair amount of glue required to cope with the existing callback-based Firefox APIs though.) How can you ever keep track of when a '}' must be followed by a ';' ? Hee hee -- dizzying, eh? Actually there are no occurrences of }; in that example, just );. In JavaScript the semicolons are optional anyway; my personal style is to use semicolons after statements but not after function declarations. 1. Variables are more appropriately scoped; they exist only where they are meaningful. (In a class, all the variables would be mixed into one namespace, where some of them would be invalid some of the time.) This doesn't strike me as very important. The same can happen in a local scope and doesn't seem to bother anyone there. That's true, but then we're talking about existing coding styles where people aren't concerned about minimizing security risks. Scopes are a very powerful tool for limiting access, but you might not notice what you're missing if you haven't been faced with a security problem and tried using them to solve it. (It's a bit like generators before we had them and got used to how handy they were: substitute scopes = generators, limiting access = flow control, security problem = concurrency problem.) 2. Local variables are private. (Class instances don't get their own private namespaces to play in.) Hmm... I wouldn't be so sure of that. Exception handlers have access to locals of stack frames above and below the current frame. True. It would be more accurate to say that local variables are usually thought of as private, and therefore could be enforced as private without breaking (hardly) anything. Making instance members private would break tons of stuff. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
Guido Well, personally I'm for allowing full rebinding semantics but Guido only when a 'global' (or 'nonlocal') statement is used Guido first. Making augmented assignment automatically imply 'global' Guido etc. seems too magical to me. So, if I understand correctly, in the presence of a global statement search just goes up the lexical chain looking for the first occurrence of the variable to modify? x = 0 def f(): x = 1 def g(): global x x = 2 print x g() print x f() print x Today it prints 2 1 2 You're suggesting it will print 2 2 0 ? Sounds reasonable to me. If we're talking py3k I'd chuck global as a keyword though and replace it with something like outer. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Musings on concurrency and scoping (replacing Javascript)
On Jul 7, 2006, at 1:08 PM, Guido van Rossum wrote:
On 7/7/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
I've been doing a bunch of Firefox extension programming in
Javascript
and suddenly a few of the recent topics here came together in my head
in a silent kapow of thoughts. This is kind of a side note to the
security discussion, but they're all interconnected: network
programming, concurrency, lexical scoping, security.
Hm... I wonder if this style has become so popular in JS because it's
all they have? I find callback-style programming pretty inscrutable
pretty soon.
You really don't have any choice without continuations or some built-
in concurrency primitive. Callbacks are slightly less painful in
JavaScript because you can define them in-line instead of naming it
first.
Client-side web scripting tends to have a callback/continuation-ish
concurrency style because it has to deal with network transactions
(which can stall for long periods of time) in a user interface that
is expected to stay always responsive. The Firefox API is full of
listeners/observers, events, and continuation-like things. So one
thing to consider is that, when Python is used for these purposes,
it may be written in a specialized style.
As i write JavaScript in this style i find i use nested functions
a lot. When i want to set up a callback that uses variables in the
current context, the natural thing to do is to define a new function
in the local namespace. And if that function has to also provide a
callback, then it has another function nested within it and so on.
function spam() {
var local_A = do_work();
do_network_transaction(
new function(result_1) {
var local_B = do_work(result_1);
do_network_transaction(
new function(result_2) {
do_work(local_A, local_B, result_1,
result_2);
...
}
);
}
);
}
How can you ever keep track of when a '}' must be followed by a ';' ?
}\n is the same as }; as far as the JavaScript spec goes, you can
do either or both.
-bob
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 and beyond
Neal Norwitz wrote: The current list of serious bugs are in the PEP: http://www.python.org/dev/peps/pep-0356/ If there are any bugs you think should be considered show stoppers, mail them to the list and I will update the PEP. http://www.python.org/sf/1519018 I believe this regression in syntax checking needs to be addressed. -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
Nick Coghlan wrote: What would the signature of the file constructor be in that case? If it's possible to call it at all, I think it would have to take a file descriptor, or whatever the platform's OS-level representation of an open file is. The other possibility is to just raise an exception if you call file() from Python code. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [slighly OT] Native speakers and hurting brains
Boris Borcic wrote: I believe that in this case native linguistic intuition made the decision... The reason has nothing to do with language. Guido didn't want sum() to become an attractive nuisance by *appearing* to be an obvious way of joining a list of strings, while actually being a very inefficient way of doing that. Considerable effort was put into trying to make sum() smart enough to detect when you were using it on a list of strings and do .join behind the scenes, but Guido decided in the end that it wasn't worth the trouble, given that he only ever intended sum() to be used on numbers in the first place. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
On 7/7/06, Greg Ewing [EMAIL PROTECTED] wrote: Nick Coghlan wrote: What would the signature of the file constructor be in that case?If it's possible to call it at all, I think it wouldhave to take a file descriptor, or whatever theplatform's OS-level representation of an open file is.The other possibility is to just raise an exceptionif you call file() from Python code.I am going with raising an exception.-Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
Brett Cannon wrote: Good point. C code could circumvent the bit check by doing all of the work behind the scenes without pushing the object on the stack. But if the check is in the C code for the object itself it is much harder to get around. C code can circumvent the bit check by calling fopen() directly and pushing something onto the stack that isn't even recognised by the interpreter as a file object :) You *have* to trust C code completely before importing it, because it has access to the platform C library and can do whatever the heck it wants. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
On 7/7/06, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote:Good point.C code could circumvent the bit check by doing all of the work behind the scenes without pushing the object on the stack.But if the check is in the C code for the object itself it is much harder to get around.C code can circumvent the bit check by calling fopen() directly and pushingsomething onto the stack that isn't even recognised by the interpreter as afile object :) Right, but you can take measures to prevent accidental circumvention. You *have* to trust C code completely before importing it, because it has access to the platform C library and can do whatever the heck it wants.Yep.-Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
On 7/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Guido Well, personally I'm for allowing full rebinding semantics but Guido only when a 'global' (or 'nonlocal') statement is used Guido first. Making augmented assignment automatically imply 'global' Guido etc. seems too magical to me. So, if I understand correctly, in the presence of a global statement search just goes up the lexical chain looking for the first occurrence of the variable to modify? x = 0 def f(): x = 1 def g(): global x x = 2 print x g() print x f() print x Today it prints 2 1 2 You're suggesting it will print 2 2 0 ? Right. And if the search finds no scope that defines x, it's a compile-time error (that's also new). Sounds reasonable to me. If we're talking py3k I'd chuck global as a keyword though and replace it with something like outer. This is still under debate. I don't think we ought to change this in Python 2.x until we've settled on the 3.x syntax and semantics; eventually (in Python 2.9 or so :-) we can backport it with a __future__ statement. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
Brett Cannon wrote: On 7/7/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 7/7/06, Brett Cannon [EMAIL PROTECTED] wrote: I guess I am just not seeing where your approach is better than preventing the constructor in 'file' and having open() return the 'file' object or proxy object. With your approach 'file' would be flagged, but with the other you just put the same check in 'file's constructor. With both you would probably also want open() to be a factory function anyway. So I don't see where you gain simplicity or more security. It seems like you are pushing the check into the eval loop, but you still require the flagging of objects as unsafe. Going with the other two proposals you don't burden the eval loop with the check but the objects that you would have flagged in the first place. It just seems like we are pushing around the flagging of unsafe stuff and that doesn't feel like it buys us much. At the risk of repeating someone's point or making no sense (I'm only following this with half an ear) I would like to point out that as long as there's C code involved, we can have the equivalent of private constructors in C++/Java. This means classes that cannot be constructed by calling the class from Python. C code has to use some other API to create an instance, bypassing this check. It seems reasonable to me, even if most popular types *can* be constructed. There are other types that have this property, e.g. list iterators. Try type(iter(list()))(). Good point. C code could circumvent the bit check by doing all of the work behind the scenes without pushing the object on the stack. But if the check is in the C code for the object itself it is much harder to get around. -Brett I may be confused (I usually am), but I think you are misinterpreting Guido's point. I think what he is saying is not you should beware of C code getting around the checks but rather he is pointing out that C code that gets around the checks can be a useful part of the system - thus the notion of private constructors, in other words methods for creating an object that are normally inaccessible to Python code. As to your point: I think I am beginning to understand, so let me reiterate to see if I have it right. In the scenario you describe, the open() function is replaced by a function that returns a proxy that has limits on what it is allowed to do. (Ideally, it would return one of several different types of proxies based on the input file path - so a file handle to /tmp would have a different set of restrictions than a file handle to /home/me.) Somewhere inside this proxy is the 'real' file handle. We need to insure that the proxy is air-tight, so that it can't 'leak' to the outside world. (The original motivation for my scheme was the belief that air-tightness couldn't be achieved, however the point that Guido makes above is beginning to make me believe otherwise.) The proxy also has to be able to support all of the methods that the regular file handle can - because we're going to want to pass that proxy over to other subsystems that don't know that they are dealing with a proxy - such as XML parsers or config file readers. Because the permission checks are implemented in the proxy, this means that library code using the proxy has exactly the same access restrictions as the sandboxed code. If you want any library code to be able to have additional privileges beyond what the sandboxed code can do, you'll need to pass them the 'real' file handle, something which can only be done by either the proxy, or by a C 'gateway' function. This is not a problem as long as the library code doesn't attempt to hold on to the file handle (otherwise then the sandboxed code could potentially grab it from the library's objects.) So for any case where a library needs additional privileges, you'll need to add additional methods to the proxy or create the gateway functions to deal with that. So if it truly is the case that the file handle cannot leak into the outside world, then you are correct - there's no need to put a check into the interpreter. My motivation was based on the belief that there would always be a way to get around that, so instead the notion was to 'poison' these protected objects so that even if they did leak out, attempting to use them in a restricted environment would fail. Moreover, there would be no need to even bother preventing such leakage - you wouldn't have to change the behavior of __subclasses__ and so on - which means that the 'restricted' environment would look nearly identical to the normal Python programming environment, i.e. you are free to inspect and use __subclasses__ or any other inspection feature as long as the result doesn't contain any poisoned objects. (BTW, I'm going to dub my idea the 'poisoned object' scheme, just so we have a label.) While I was typing this, I did realize a drawback to
Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
On Fri, 7 Jul 2006, Talin wrote: While I was typing this, I did realize a drawback to poisoned objects, which I will illustrate by the following example: Suppose we want to grant to the sandboxed program permission to read and write cofiguration properties. We don't want to give them arbitrary write access to the file, instead we want to force the sandbox code to only access that file by setting and getting properties. This is an example where a subsystem would require elevated privileges compared to the main program - the config file reader / writer needs to be able to read write the file as a text stream, but we don't want to allow the sandboxed program to just write arbitrary data to it. The situation you're describing here is a classic case of one component keeping a closely held authority while using it to provide some limited capability to some other component. This comes up quite often when you're trying to write secure code. If you want to be able to write that subsystem in Python, then we will need a way to create airtight Python objects (i.e. objects that only leak what they explicitly choose to leak). So this goes back to the big question of goals: Do we want to be able to protect one piece of Python code from another piece of Python code? I'd like the answer to be yes. It sounded for a while like this was not part of Brett's plan, though. Now i'm not so sure. It sounds like you're also interested in having the answer be yes? Let's keep talking about and playing with more examples -- i think they'll help us understand what goals we should aim for and what pitfalls to anticipate before we nail down too many details. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
On 7/8/06, Ka-Ping Yee [EMAIL PROTECTED] wrote: The situation you're describing here is a classic case of one component keeping a closely held authority while using it to provide some limited capability to some other component. This comes up quite often when you're trying to write secure code. If you want to be able to write that subsystem in Python, then we will need a way to create airtight Python objects (i.e. objects that only leak what they explicitly choose to leak). So this goes back to the big question of goals: Do we want to be able to protect one piece of Python code from another piece of Python code? I'd like the answer to be yes. It sounded for a while like this was not part of Brett's plan, though. Now i'm not so sure. It sounds like you're also interested in having the answer be yes? Let's keep talking about and playing with more examples -- i think they'll help us understand what goals we should aim for and what pitfalls to anticipate before we nail down too many details. I'd like the answer to be no, because I don't believe that we can trust the VM to provide sufficient barriers. The old pre-2.2 restricted execution mode tried to do this but 2.2 punched a million holes in it. Python isn't designed for this (it doesn't even enforce private attributes). I guess this is also the main reason I'm skeptical about capabilities for Python. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
Anthony Baxter wrote: On Saturday 01 July 2006 12:55, Guido van Rossum wrote: It's up to the release manager now to decide whether the pitchforks at Google or the pitchforks in the larger Python community are sharper. ;-) At this point, I think removing the warning code is the prudent course. If someone wanted to find an easy and safe way to make it only be triggered when the import fails, it could stay in. I created a patch (#1515361) intended to do just that. https://sourceforge.net/tracker/index.php?func=detailaid=1515361group_id=5470atid=305470 Unfortunately, something appears to be misconfigured in my ISP's mail server, and as a result, my messages aren't making it to this list. So you may not have noticed Guido's re-posting of my message announcing the patch. Shane ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
