Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.wizards Subject: Re: file attributes Message-ID: Date: 22 Jun 91 17:54:10 GMT References: <1767@sranha.sra.co.jp> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 51 In-Reply-To: erik@srava.sra.co.jp's message of 22 Jun 91 08: 07:44 GMT Although the original motivation for the request might be questioned there are perfectly good reasons to extend the inode/file structure to allow for the storage of file attributes. One common reason this comes up is to implement access list protection (where we store a list of pairs, user/permissions.) This is required (or the accepted way to meet standards) by one of the Orange Book classifications (B2 I believe.) The obvious way to do this is to have a secondary inode for a file pointed to by the primary (data) inode, basically an anonymous file with a new file type. This anonymous inode is otherwise like a regular file, but can not be linked to a directory name and is freed when the file is freed. It should be optional with some typical convention (e.g. if the anonymous inode is zero then there is no anonymous inode for this file.) So from the file system's point of view it requires the addition of an integer (ino_t) to the inode struct (probably available as an unused in many implementations), and a few checks here and there to enforce policy (e.g. link() returns EANOM or some such.) A reasonable convention might be one echoing the environment variable conventions (NAME=VALUE) although admittedly it's difficult to store lists (arrays) of values in that format, other than simply storing them in the value and using string processing software to unpack them, not entirely unreasonable. Given this it would be straightforward enough to implement any desired operations, I believe all you really need is a flag to open(2) telling it to return a file descriptor for the anonymous inode rather than the data file. From then on standard file ops should be sufficient (read(), write(), close(), fchmod(), etc.) to use the new feature. A few library (3) routines would help maintain conventions. There are many other uses of such files beyond GUI's. This conversation got a little side-tracked by the original request topic (it would be like someone first suggesting environment variables, but citing a questionable reason for needing them.) I know of at least one large unix vendor who was implementing this idea a year or two ago. If a process can have environment variables I don't find it completely peculiar that a file might also. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD