Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.wizards Subject: Re: filenames with a '/' -- help Message-ID: <2901@auspex.auspex.com> Date: 6 Feb 90 18:06:50 GMT References: <22167@adm.BRL.MIL> <2845@auspex.auspex.com> <25C7178C.6F8@marob.masa.com> Distribution: usa Organization: Auspex Systems, Santa Clara Lines: 27 >Not quite. What 'open' would really do under this scheme would be to accept >a >capability< for a directory, plus a file name, and return a capability >for the file in question. A capability differs from an inode because it >contains coded information that validates the user's access rights. I indicated that by "inode" I'd presumed they meant "reference to the inode"; one such reference could be a file descriptor opened to the file (modulo, presumably, ways of having file descriptors for directories "open for searching", and the like), which, in effect, is a capability to the inode - or, if you will, a reference to a capability to the inode, the actual capability being stored in the kernel. Inodes are rather big, so there's a saving from handing around references to them rather than handing them around directly. >A reasonable way to implement capabilities would be to use the inode plus >some random bits. For each capability, the kernel must retain a copy of it, >and whenever a capability is passed in, the kernel checks whether it is >valid. This makes Unix permissions syntax easy to arrange by having different >capability-bit combinations for the various permission rights. Naturally, >the relation between the permissions themselves and the bits should be >protected by a cryptographically strong transformation.... How is this better than just handing around what amounts to references to those capabilities? (There are several ways of protecting capabilities, including simply making them not writable by non-privileged code, which is what "file descriptors as capabilities" does.)