Mailman 3 December 2003 - Python-Dev

Re: [Python-Dev] Re: rexec.py unuseable
by Michael Chermside 18 Dec '03

18 Dec '03

Luke: Seeing as you've now had time enough to read what I'd written, I was going to respond to some of the points that you made, but then I read Nick Coghlan's posting[1], and I really don't have anything else to add. [1] http://mail.python.org/pipermail/python-dev/2003-December/041105.html Well, that's not quite true... I guess I _do_ have something small to add. In designing a security policy for file systems, there are very few things that you can do with the protected items. Separate "read", "write", and "execute" permissions seem appropriate. Furthermore, there tends to be a clear idea of a "user", and in many situations we want all access to items (files) to depend only on who that "user" is (sandboxing an email program is an exception... are you listening MS?). Finally, we often want to provide centralized administration of access rights to file systems. ACLs are a good match for these design specs. However, controlling what arbitrary programs may do is a very different beast. First of all, the kinds of restrictions that we want are HIGHLY variable. Sometimes we want to prohibit all file access. Sometimes we want to allow read-only access to a certain file only. Sometimes we want access only to a certain directory. Sometimes we don't care at all about file system access, we're concerned instead with providing an object which can be queried but only in certain ways -- and the specifics of what is permitted and what isn't are completely dependent on the particular application. On top of that, there's rarely a clear concept of "users" that controls what actions we want to permit. Instead, we usually want to allow or deny certain capabilities to particular _sections of code_. (Sometimes that will be a module, sometimes a plug-in, sometimes a child program.) All of these things suggest that maintaining a list of who is permitted to access what is simply not the best model for providing security in a programming language. I think that capabilities ARE an excellent model. Sections of code already have the concept of "access" to certain objects and variables (at least since the invention of structured programming in the late 1960s). And _if_ unforgability and private data structures are provided as elemental building tools, then it is relatively straightforward to write code that enforces whatever set of access rules is required, regardless of how complex it may be. -- Michael Chermside

3 3

Re: open == file considered harmful (Re: [Python-Dev] RE: rexec.pyunuseable)
by Luke Kenneth Casson Leighton 18 Dec '03

18 Dec '03

> Are you aware of the original issue, which is that as soon as you have > a file *instance* (which might have been given to you by a very > restrictive open() variant), you can always get to the file *class* > using the __class__ attribute? Access to the __class__ attribute is > useful for all sorts of reasons. that is why i am proposing that ACLs be added to every "Entity" in language - functions, modules, attributes etc. [even if the implementation is such that they aren't _actually_ every-object-in-python-has-another-damn-pointer] in this way, you would have one ACL on the open() function which restricts it to file-read-only, another ACL on the open.__class__ attribute which would be, for the sake of argument [("all functions", DENY, ABSOLUTELY_EVERYTHING)] etc. l.

1 0

Re: [Python-Dev] rexec.py unuseable
by Luke Kenneth Casson Leighton 18 Dec '03

18 Dec '03

> the two as I understand it. I must admit I am quite curious about the > fact that you seem to have plenty of time to _write_ about your > proposal, but no time to listen to some quite reasonable responses. nick, thank you for pointing this out. that i do not explicitly acknowledge other people's point is a common failing of mine that has frequently got me into significant communication difficulties. yes i _do_ appreciate and understand what people say, and take the time to read it: i don't necessarily always actually explicitly say that and i really appreciate you picking up on this. if anyone else who is responding on this thread feels offended because they do not believe that i am listening to what they have to say PLEASE SAY SO. thanks, l.

1 0

Re: open == file considered harmful (Re: [Python-Dev] RE: rexec.pyunuseable)
by Guido van Rossum 18 Dec '03

18 Dec '03

[Michael Chermside] > I disagree. Right now, having access to a class object basically > gives one the ability to create new objects of that type. I > think that's just fine... and I don't mind applying it to the > file object. I'd think that the thing to do with untrusted code > is to deny it access to the 'file' type object, thus denying it > the ability to create new 'file's directly. > > After all, it's not like file has lots of useful classmethods... > client code which is not supposed to create new files has no > particular need to access the 'file' object. Oh yes, except > that it may have INSTANCES of 'file' and could access > f.__class__. But if it is RESTRICTED code, then the only > legitimate use of f.__class__ is to do typechecking (it's > arguable whether that is good design, but it does seem to be > a legitimate use), so for restricted code we return something > like this: > > class FakeFile: > def __eq__(self, other): > return other == file > > [...] Are you aware of the original issue, which is that as soon as you have a file *instance* (which might have been given to you by a very restrictive open() variant), you can always get to the file *class* using the __class__ attribute? Access to the __class__ attribute is useful for all sorts of reasons. > Guido writes: > > Re the capabilities discussion, this is Python 3.0 material if I ever > > saw some > > I agree. But I can dream, can't I? <wink> Yes, even for 3.0 this is still a dream... --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

RE: rexec.py unuseable
by Michael Chermside 17 Dec '03

17 Dec '03

I (Michael) wrote: [Speaking of how to provide restricted execution in Python] > 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 Luke replied: > capabilities, acls, schmapabilities, same thiiing :) No... they're not. Read the thread I mentioned above, or read this, and some of the other documentation for the language E: http://www.erights.org/elib/capability/ode/ode-capabilities.html Later Luke writes: > btw yes you're right, it's better off called "capabilities" > but the name CCLs - capability control lists - is a bit of > a mouthful :) Again, I mean something different, NOT CCLs, but capabilities. Hmm... how about a quick summary from me (but I'm not an expert). Suppose that had some code which had an object representing a directory, with a method "open(filename, mode='r')" that opened files in the directory. Given this object, you could imagine constructing new objects with more limited capabilities. For instance, you might create a readOnlyDirectory object which had a method "open(filename)" that didn't allow specifying the mode as anything but 'r'. Or you might open a file and then pass a file object with "read()", "write()", "seek()", and other such methods, which would only access that file. So _IF_ the only way to access files were through this object (and that's a BIG if), then you could imagine a world where HAVING and object was equivalent to being able to do something. If a bit of code had access to a read-only-file object then it could read that file, but couldn't write to it, or do anything else with the file system unless it ALSO had access to some OTHER objects. That's capabilities... and it would work for most kinds of restricted resources, not just the file system. The key idea is that HAVING a pointer to the object is equivalent to having the permission to USE that object, and whatever it provides access to. There are several ways to "escape" out of this system. One way is to access some global ability... for instance, you might use the "open()" function from __builtins__. For capabilities to work in Python access to "dangerous" globals would need to be restricted. Another way is to just create an object out of nowhere, or forge a pointer to an object. Fortunately, in Python these are already impossible... pure Python code cannot forge references or create objects without access to the type or class. (C extensions can do anything and are unsafe.) Another way is to access the more powerful object that "empowers" a less powerful one... perhaps using the (supposed to be private) _directory field in the readOnlyfile object. So capabilities in Python are impossible without some sort of private data for objects (this is not a particularly onerous requirement). Yet *another* approach would be to use introspection... for instance, in Python today, given any file object, the class itself ("file") can be obtained via introspection, and then used to create other file objects. Using capabilities in Python would require that "restricted" objects have some more limited form of introspection... perhaps one could only obtain a "fake" class object which had a __equals__ method that simulated being the real class, but which had no __init__ so it couldn't be used to create new instances. At any rate, you get the idea. Capabilities are possible in Python only if some sort of "restricted mode" is created, which restricts access to some built-in abilities and which creates "restricted" objects with some private data and limited introspection. But IF you had these things (and they're NOT trivial), then capabilities may be a conceptually more elegant approach than ACLs, lleading to more elegant programs. -- Michael Chermside

6 7

Pie-thon benchmarks
by Dan Sugalski 17 Dec '03

17 Dec '03

Not to push, folks, but the python dev community was going to write the benchmark program for the pie-off Guido and I are going to have at OSCON 2004. We're supposed to have the bytecode for the program frozen by the end of December 2003, a mere 16 days away. (I could just go with pystone, I suppose, but even .NET's faster on that one...) -- Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan(a)sidhe.org have teddy bears and even teddy bears get drunk

8 22

Re: Python-Dev Digest, Vol 5, Issue 57
by Edward Loper 17 Dec '03

17 Dec '03

Guido said: > There is the remaining issue of what exactly the syntax would be. I > propose to extend the from clause to allow one or more dots before the > dotted name, and to make the dotted name optional if at least one > leading dot is found. I propose not to change from-less import. What's the motivation for restricting it to from-imports? I suspect that this will cause confusion, and it doesn't feel self-consistent to me: why can you call a module ".foo" in one context, and not in another? In particular, I think that if people see that you can do: from .foo import * Then they'll assume that they can also do: import .foo With the obvious semantics, i.e. equivalence to: from . import foo What do we gain by not extending the syntax to from-less imports? -Edward

3 2

RE: [Python-Dev] Relative import
by Batista, Facundo 17 Dec '03

17 Dec '03

Guido van Rossum wrote: #- There is the remaining issue of what exactly the syntax would be. I #- propose to extend the from clause to allow one or more dots #- before the #- dotted name, and to make the dotted name optional if at least one #- leading dot is found. I propose not to change from-less import. Don't know the restrictions, as never used the package feature in modules, but seems natural to me to use the same syntax that in a unix filesystem (maybe without the '/'?). This way, you can reference a module in your level, in an upper level, etc... . Facundo

1 0

Filename suffix default for command line
by Raymond Hettinger 17 Dec '03

17 Dec '03

Would there be any disadvantage to checking for filename.py whenever filename is not found so that "super.py" could be invoked with either "python super.py" or "python super"? Raymond Hettinger

3 2

instancemethod_getattro seems to be partially wrong
by Christian Tismer 17 Dec '03

17 Dec '03

Hi again, again! After hours of investigating why my instance method __reduce__ doesn't work, I found out the following: instancemethod_getattro does this: if (PyType_HasFeature(tp, Py_TPFLAGS_HAVE_CLASS)) { if (tp->tp_dict == NULL) { if (PyType_Ready(tp) < 0) return NULL; } descr = _PyType_Lookup(tp, name); } f = NULL; if (descr != NULL) { f = TP_DESCR_GET(descr->ob_type); if (f != NULL && PyDescr_IsData(descr)) return f(descr, obj, (PyObject *)obj->ob_type); } Why, please can someone explain, why does it ask for PyDescr_IsData ??? I think this is wrong. I'm defining an __reduce__ method, and it doesn't provide a tp_descr_set, as defined in... int PyDescr_IsData(PyObject *d) { return d->ob_type->tp_descr_set != NULL; } but for what reason is this required??? This thingie is going wrong both in Py 2.2.3 and in Py 2.3.2, so I guess there is something very basically going wrong. I'd like to fix that, but I need to understand what the intent of this code has been. Can somebody, perhaps the author, explain why this is this way? thanks so much -- chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

5 19