following on, with a change of subject, from the rexec / acls discussions, i believe that i have finally worked out why acls are not the preferred way forward, leaving speed disadvantages aside. ACLs need to be applied subtly and explicitly on every important type of object. if they're not designed in at the time they are a PAIN to retro-fit. ACLs need to be applied subtly because if they are applied unsubtly you end up with more gates than you do green pastures - more roundabouts than roads (viz, milton keynes). ACLs need to be applied explicitly because of their nature: you have something (it could be the right to "see" something) and you try do _do_ something and are explicitly told whether it worked or not (or are explicitly fooled into believing that something cannot be "seen). from a code security review perspective, it's actually easier to review ACL-restricted code than it is capabilities-based code, but i'll expand on that later. Capabilities are like the difference between python 0.0 and python 2.5. python 0.0 is "capable" of doing certain things - however python 2.5 is "capable" of doing a heck of a lot more, simply because the functionality in python 0.0 doesn't _exist_. The principle behind Capabilities is therefore to simply _not give_ python 2.5 users _any_ means to use, view, see, certain functionality i.e. make it look like it doesn't exist. in other words [and this is the bit that i could _really_ have done with, two days ago], when a python user accessess __globals__, __builtins__, __locals__, an object's __class__, they find that the functionality they may be looking for literally _isn't there_. it's as if someone had recompiled python 2.5 #ifdeffing out a whole boat-load of code and forgot to include some modules. the advantage of Capabilities over ACLs is that there's no chance of making a mistake on the ACLs, because access to something that, as far as the user is concerned, doesn't _exist_, is just a non-issue. the other advantage is speed. the _dis_advantage of Capabilities over ACLs comes when an attempt to combine unrestricted Capability code with restricted Capability code in the same codebase is made, and a security audit is called. the nature of restricted Capabilities is such that it is "by omission" that you achieve security. how the heck are you going to do a security audit looking for things that are omitted, rather than included, especially in amongst a full set of code that has the full functionality? by contrast, with ACLs, you can check everything (in a regimented fashion) and if it don't have an ACL, you can at least ask _why_ it don't have an ACL. so, with that explanation in mind, i'm going to write up a separate message outlining some of the ways in which i believe the capabilities restriction system that is already in python can be improved. l.