Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!uunet!mcsun!dxcern!vxcrna.cern.ch!roeber From: roeber@vxcrna.cern.ch Subject: Re: A challenge to all true hackers: objects and types Message-ID: <1993Mar26.222417.1@vxcrna.cern.ch> Sender: news@dxcern.cern.ch (USENET News System) Reply-To: roeber@cern.ch Organization: CERN -- European Organization for Nuclear Research References: <C4FEo2.8no@sugar.neosoft.com> <1osl3b$8vl@umd5.umd.edu> <1993Mar25.184157.1@vxcrna.cern.ch> <1ov988$5l6@umd5.umd.edu> Date: Fri, 26 Mar 1993 21:24:17 GMT Lines: 43 In article <1ov988$5l6@umd5.umd.edu>, mark@roissy.umd.edu (Mark Sienkiewicz) writes: > [...] > This means that looking up files does not require special powers? How _do_ > you handle things like security? I ask because it is sounds like the > Apollo system allows user processes to open any arbitrary _inode_ (well, > inode-equivalent) on the system. This would pretty much destroy most > file security unless you did something else about it. e.g. file permissions > on a directory would no longer have much meaning. In Apollos, the storage system and the naming system are separate. The "filesystem" uses UIDs -- Unique identifiers, what you called "inode- equivalent"s (They're a combination of a timestamp and a machine ID). Though the calls aren't documented, you can (try to) open any file given its UID. Each disk has a "volume table of contents" (VTOC) which stores the UID<-->physical location database. The naming system translates a path into a UID. A file's access settings (Apollos use a combination user/group/org/world mask plus ACLs) are associated with a UID, not a directory slot. When you try to open a file via its UID, your permissions are checked against the file's access settings. When you use the naming system to resolve a path into a UID, at every step along the path you are checked for search permissions in that directory. So yes, though you might set a top-level directory to have very restricted permissions, someone who knows (or guesses) a file's UID will be able to acces it *if that file's access settings allow it*. This is different from the traditional inode bug, in that though you can subvert directory search permissions by guessing a UID, because the access settings pointer is stored in the VTOC, you are still have to pass the file's permissions. However, it displeases people who take the strict approach of "if I set a directory to deny some access, everything beneath it has that access denied." -- Frederick G. M. Roeber | CERN -- European Center for Nuclear Research e-mail: roeber@cern.ch or roeber@caltech.edu | work: +41 22 767 31 80 r-mail: CERN/PPE, 1211 Geneva 23, Switzerland | home: +33 50 20 82 99