Luke Kenneth Casson Leighton wrote:
> 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.
I don't think this discussion is going to get anywhere until you _do_
take the time to understand the difference between the model you are
proposing and the capability model that seemed to be preferred the last
time executing untrusted Python code safely was discussed.
ONE LINE SUMMARIES
ACL/CCL/whatever you want to call it:
Access the feature, then have permission either granted or denied
Capabilities:
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.
Below is my attempt at explaining in more detail the difference between
the two as I understand it. I must admit I am quite curious about the
fact that you seem to have plenty of time to _write_ about your
proposal, but no time to listen to some quite reasonable responses.
ACCESS CONTROL LISTS
An access control list is neutral to what a 'user' is, so I'll switch to
the term 'Entity' instead. The important part is that it is a mapping:
"Entity X is allowed to perform action Y on other Entity Z".
It serves as a post hoc check - _after_ Entity X tries to do Y to Z, the
control list for Y & Z is checked, then X is either allowed to proceed,
or told to rack off, depending on what the control list reports. That
is, just because X _can_ try to perform action Y on Z (the relevant
method or whatever is accessible to X), doesn't mean that X _may_
perform action Y (the control list grants permission to X).
With control lists, the concepts of access to a feature, and permission
to use that feature, are handled separately. E.g. I can try to delete
the windows directory on my machine at work (I have access to that
directory, and access to the delete command), but I'm not an
administrator, so the attempt will fail (I don't have permission to
delete that directory). This is exactly what you are describing, even
though the users are 'functions' rather than 'logged in users'.
CAPABILITIES
Capabilities work differently. Instead of applying a post-hoc check that
slows down _every_ attempt to perform an action, they unify the concepts
of 'can' and 'may'. If X is able to express the command "do Y to Z",
then X is also _permitted_ to do Y to Z. No post-hoc checks required.
For example, suppose I wasn't allowed to open writable files.
I call:
>>> target = file("myfile.txt", "w")
With ACL's, I would get an error along the lines of:
AccessDenied: No permission to open writable files
With capabilities, I would get an error along the lines of:
InvalidArgument: "w" is not a recognised file mode
Does this make any more sense?
Cheers,
Nick.
--
Nick Coghlan | Brisbane, Australia
Email: ncoghlan at email.com | Mobile: +61 409 573 268
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4