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

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue Dec 16 16:36:58 EST 2003

On Tue, Dec 16, 2003 at 10:04:40PM +0100, Jack Jansen wrote:

On 16-dec-03, at 17:16, Luke Kenneth Casson Leighton wrote: >>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 > > no offense intended: i'll read that later, i'm running out of time. > > without going into too many definitions, consider what i am advocating > to be like an access control list but instead to be a capabilities > control list, instead. The distinction between capabilities and ACLs is really important, because they are almost each others opposite. 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.

i'd like to introduce you to a new concept which is idential in form to an ACL - access control list - except that instead of "users" being allowed or denied access to perform certain operations you have instead functions being allowed or denied access to perform certain operations.

perhaps a better way to explain the concept to you is to introduce a concept called "qualified" capabilities, where what you know of as capabilities is "qualified" on a per-function (that's per-caller) basis.

obviously, any object (by object i am referring generically to classes, class instances, functions, modules, absolutely anything) can potentially have many "callers", consequently it is necessary to create a list of qualified capabilities, and for the relevant QCap in that list to be looked up and applied as needed.

where, of course, the special wildcard name 'all functions' applies to all callers.

which makes what i am proposing to be named

"QCCL" - qualified-capabilities control list.

yuk :)

l.

More information about the Python-Dev mailing list