ACL's, Capabilities, Priv-Bits & other fs meta-data

Jim Dennis (
Mon, 02 Mar 1998 02:00:36 -0800


I realize I'm probably just displaying my ignorance here but I have
a question about how we intend to extend ext2fs (or ext3?) to
support ACL's, "Orange-Book" privilege bits, capabilities, and/or
other file/directory meta data.

I don't like the idea of significantly enlarging the inode structure
to support these sorts of features, particularly if only a small
percentage of the files on any given system will be using them.
(It seems likely to me that Unix/Linux sysadmins will continue to
use traditional Unix permissions bits wherever possible, and only
*resort* to ACL's (etc) when then *need* to do so.

One thought occurred to me: what if we only add a pointer to
a "resource fork" (not really much like the Apple/MacOS "resource fork"
-- so perhaps we should call it something different, like the
meta data field). I guess this would actually be a pointer to another
inode -- one normally had no directory entries (links). Then arbitrary
amounts of meta data could be encoded into the data on this other

This would be extensible -- and would have no effect on the inodes
that had no "meta-data" associated with them (presumably the majority
of files and directories for the majority of fs').

Another (probably uglier) way that occurs to me is to have a "shadow"
fs with meta data in it. I haven't thought about that beyond just
mentioning it here. I suppose an advantage of a "shadowfs" is that
it would allow one to add/overlay ACL's and other semantics over
existing fs types. It might offer some marginal performance advantages
(if one made it a point to put the shadow/overlay on a different spindle
from it's associated fs.

As usual I'm speaking on a purely theoretical basis here. My real
question is: how were we planning on adding most of these extensions
to the fs'. It seems like I've read about a bunch of different patches
to ext2fs (from GNU HURD's "watchdog" file system objects to Andrew
Morgan's "privs" to several ACL's systems and a few logging and/or
journaling fs').

Jim Dennis  (800) 938-4078
Proprietor, Starshine Technical Services:
        PGP  1024/2ABF03B1 Jim Dennis <>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A 

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to