[Python-Dev] rexec.py unuseable

[Luke Kenneth Casson Leighton]

On Tue, Dec 16, 2003 at 09:14:40PM +0100, Martin v. L?wis wrote:
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> writes:
> 
> > > Also, it seems that nowhere in your proposal you state how ACLs should
> > > be integrated into Python: I.e. what objects are protected by ACLs,
> > 
> >  all objects - if an acl is non-null.
> 
> Does this include functions and bound and unbound methods?
 
 if it's a function, it can potentially have an ACL (or a
 better description is CCL - capabilities control list) added,
 and that CCL applies to all sub-objects of the function.

 same with objects, classes - everything.

 

> > >   3 * 4
> > > 
> > > Is that read, write, execute, and which ACL(s) is(are) considered?
> >  
> >   execute, and execute only, because there's no I/O involved.
> > 
> >   on the multiply operation.
> 
> So what operations require read or write access?

 short answer: all of them.
 
 longer answer: just like with exceptions, that has to be classified
 according to conventions that are yet to be decided.

 i propose that, for example, a capability be created to control _file_
 read access and _file_ write access, with large provisos on the
 documentation attached to these two capabilities that ensure they are
 distinguished from the right to _modify_ an object.


 basically it's all conventions, just like exceptions are conventions.

 all i can do is recommend a framework and some guidelines on what
 conventions could be fitted over that framework.

 heck, it may even be worthwhile defining a low-level object, named
 a Capability, just like an Exception is defined, and then expect
 people to create their own, and recommend the creation of certain
 Capabilities that are inherited from the Capability base class.


> >   but _only_ if there's an actual ACL set _on_ the multiply function.
> > 
> >   if there's no acl set on the multiply function, there's no
> >   restrictions on the multiply function.
> 
> So ACLs on the objects 3 and 4 would be irrelevant?

 well... actually.... no :)

 but are such ACLs relevant?

 can you do 3 += 5?

 no you can't: python throws up a SyntaxError: can't assign to a
 literal.

 so, whilst the answer is yes, you _can_ associate an ACL [or
 better-named, a CCL] with the object "3" and the object "4",
 i would be surprised if there were any situations where they got...
 hang on...

 >>> dir(3)
 ['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__',
 '__delattr__', '__div__', '__divmod__', '__doc__', '__float__',
 '__floordiv__', '__getattribute__', '__getnewargs__', '__hash__',
 '__hex__', '__init__', '__int__', '__invert__', '__long__',
 '__lshift__', '__mod__', '__mul__', '__neg__', '__new__',
 '__nonzero__', '__oct__', '__or__', '__pos__', '__pow__', '__radd__',
 '__rand__', '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__',
 '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__',
 '__ror__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__',
 '__rtruediv__', '__rxor__', '__setattr__', '__str__', '__sub__',
 '__truediv__', '__xor__']

 yes, i believe it _might_ be relevant to set a CCL on an object "3"
 because someone might want to restrict how... oh, i dunno... mmm.
 __setattr__ gets used.

 >>> 3.__xor__
            ^
  SyntaxError: invalid syntax

 oh.  maybe not :)


 however, a UserLong or a UserInt is a different matter.

 [btw, change of subject: why is there no __eq__, no __gt__, no __le__
  in that list above?]




> Generalizing this, given a class Foo, with a method bar(), and two
> instances foo1 and foo2:
> 
> foo1 = Foo("/etc/passwd")
> foo2 = Foo("/tmp/nonexistant.yet")
> 
> and considering the calls foo1.bar() and foo2.bar():
> 
> Given that *only* the ACL on the operation bar matters: Does that mean
> that the calls either both succeed or both fail, for a given caller?

 i'm not entirely sure what you mean, but let's assume that objects
 (and their instances!) all have an __set_ccl__() function.

 let's also define a CCL:

 deny_ccl = [('all functions', DENY, 'execute')]

 then, let's try this:

 foo2 = Foo("/etc/passwd")

 Foo.bar.__set_ccl__(deny_ccl)
 foo1 = Foo("/etc/passwd")

 foo2.bar() // executed okay
 
 foo1.bar()
 *** EXCEPTION: execute capability barred to "all functions".

 
 okay, let's try this, first making sure there's no ambiguity by
 re-setting the CCL on the Foo class:

 Foo.bar.__set_ccl__(None)

 okay, now we go:

 foo3 = Foo("/etc/passwd")

 foo3.bar() // executed okay
 foo3.bar.__set_ccl__(deny_ccl)

 foo3.bar() 
 *** EXCEPTION: execute capability barred to "all functions".

 
 note that there are three separate uses of __set_ccl__().

 first is to set a CCL on the _class_ Foo.
 second is to clear a CCL the class Foo.
 third is to set a CCL on an instance of a Foo object.

 just to clarify: i _may_ have just violated my own proposal
 by not setting an "inherited-on-create" capability on the CCL named
 deny_ccl.

 the reason for needing to have such a capability is to be able to
 distinguish between setting CCLs on a class and a CCL being
 created on an object when an instance _of_ that class is created.

 this is part of the lesson learned from NT's security model
 (and originally VMS's) and its implementation.

 
 i won't go into more details on this inherit-on-create thing
 until the rest of the stuff sinks in :)

 l.