Messages in this thread | | | Date | Mon, 4 May 1998 14:30:16 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: [patch 2.1.97] more capabilities support |
| |
Date: Sat, 02 May 1998 02:25:33 +0200 From: Andrej Presern <andrejp@luz.fe.uni-lj.si>
But of course I'm assuming object-oriented design. Because no matter what way you look at it, every operating system is consisted of objects, even though borders between them may be very blured due to a limited access control mechanism used, such as ACLs or capability lists, that prevents efficient fine grained access control for one reason or another.
My point was that capabilities pre-date objects, and most folks do not assume that capabilities automatically assume an object-oriented interface. So you're using the term quite differently than many folks would typically understand you. It's certainly different from much of C.S. literature which discusses capabilities.
> Suppose the interface involved is "purchase an item". If that is the > interface, than a check at the "object border" can only be, "allow the > user to purchase an item". However, this is not useful; we may want to > express the authorization "allow the user to purchase items under > $5,000". Or perhaps the authorization rule is "allow the Ted to > purchase normal items under $5,000 but not radioactive chemicals > (because he hasn't taken the radiation safety course yet)."
I really don't see why this should be a problem with capabilities.
The problem is that you usually want access control decisions at a finer-grain that objects. For example --- a file is an object. But an access control at the object boundary gives you an "all-or-nothing" access to the object. You might want to give someone read-only access to the object. Or perhaps only the ability to append to the object. And so on.
In the case of account purchasing, which I used above, you want access control at a finer grain than the object, which is the account. I might have the ability to purchase up to $5,000 against the account. Or to purchase items but not approve travel vouchers. Or buy checmicals but not anything that is radioactive. These are all very object-specific access controls that you can't just do at the boundary.
You can do this sort of access control using traditional capabilities, but the authorization checks and the capaibilities have to application and object-specific. You can't just do them at the object boundary, as you seem to want.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |