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

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-list mailing list