[Python-Dev] rexec.py unuseable (original) (raw)

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue Dec 16 16:23:12 EST 2003

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.

More information about the Python-Dev mailing list