On Apr 7, 2004, at 3:58 PM, Rodney M Dyer wrote:
At 06:26 PM 4/7/2004, you wrote:
Not that an in-memory credential cache would make any difference in this situation.
If you have root privs you can access it. This is true on Windows as well. If
you are SYSTEM you can do whatever you want.
True. But that problem only occurs because the kernel code allows all memory to be read by "root". It would be nice if all OS's has a "protected store" memory area who's sections could only be mapped to each authenticated user. Don't ask me how...I just work here.
Capabilities solve that problem. With a capability OS, all OS objects (processes, files, directories, device drivers, etc.) are distinct entities that have a unique identity and a unique set of "capabilities". The capability is like an ACL, in that it specifies exactly what each other object is or isn't allowed to do to that object. In a combination of OO and AFS thinking, think of it like every object has a token, and instead of an AFS-like defined set of ACL attributes, every method for that object ("read", "write", "open", "delete", "send", "encrypt", "decrypt", etc.) has a list of other objects that may or may not use that method.
But that's a sort of shallow summary from someone who hasn't really looked at capabilities in a few years. Unix would require a lot of re-working to function with capabilities (for one, the unix style permission model is _gone_ in a capability OS). I'm not sure how well mach would adapt to it ... and I'm not sure what it would look like to have a mach kernel with a capability middle-layer and then a unix layer on top of that (but, that has been my idea about how to bring capabilities to unix). It may end up that your "unix" environment ends up being 1 capability object, or something ... which means you're not really using capabilities within unix.
AFS and Kerberos have a problem here in that everytime you spawn a process or create a file, you's have to create a new principle. So, instead of using AFS/Kerberos as your identity model, you have to think of the kerberos ticket or AFS token as a specific object, and then the ticket/token object has ACLs for who and what may access it (and how they may access it).
Anyways, for more info about Capabilities (now that I've mentioned them twice in a short time), here's some links:
(google search that has some good results)
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF -8&q=Capability+Based+Operating+Systems&btnG=Google+Search
The first 3 major results are "EROS", "J-Kernel" and "Cap-lore". EROS is a capability oriented OS, which looks interesting (and their "about" pages do describe the basic concepts of capability systems). Cap-lore is oriented around the theories in general. I haven't seen nor used J-Kernel.
EROS' description of Capabilities can be found at:
http://www.eros-os.org/project/novelty.html#capabilities
(I've also had the plan-9 people tell me that they think of their file name space to effectively be a capability system, in that being able to name an object is the same as being able to use/access it, so if you don't want your inheritors to access you, you remove yourself from their name space ... but it's not a strict one, because they can essentially add you back without your being able to deny that)
_______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
