Access Control (was Re: [Python-Dev] rexec.py unuseable) (original) (raw)

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Dec 17 14:58:46 EST 2003

okay, to recap.

jack jansen explains the difference between capabilities and ACLs:

With capabilities you have an (unforgable) right to do something
and no-one cares about your identity.

with ACLs you have an unforgable identity which is checked against
the ACL.

nick coghlan gives a definition of a capability as:

If you can access it, you have permission to use it.
If you aren't allowed to use it, you won't even be able to see it.

nick coghlan also gives a definition of an access control list as:

"Entity X is allowed to perform action Y on other Entity Z".

where an "Entity" may be an object, a function, a user, a module, an identity - anything - but in the context of the python language, it is presumed that "Entity" definitely NOT include "user" or anything remotely connected to the host operating system's concept of "identity".

luke leighton defines "action Y" as sufficiently general to include "seeing" as well as "doing".

[the reason for such is that the purpose of capabilities
 may then be perceived to be a subset of the purpose of ACLs.]

nick coghlan describes capabilities as a "post-hoc check" which he then concludes that, by nature, the use of capabilities is therefore fast.

mike chermside succinctly explains the need for fine-grained access control down to code-section level, but he disagrees with the necessity for having lists of access controls.

luke leighton endeavours to justify his opinion that capabilities are appropriate for functional languages c but completely inappropriate for object-orientated languages like python (the function() and the class thing).

luke leighton gives a waffly explanation of the NT security descriptor concept and provides some example usage in NT services. he also gives some example ways by which NT SDs could be adapted for use by the python interpreter.

guido goes agog and type-casts this discussion as definitely python 3.0-esque.

l.

More information about the Python-Dev mailing list