file attributes

[Barry Shein]

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 at world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD