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
"fork."
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 consulting@starshine.org
Proprietor, Starshine Technical Services: http://www.starshine.org
PGP 1024/2ABF03B1 Jim Dennis <jim@starshine.org>
Key fingerprint = 2524E3FEF0922A84 A27BDEDB38EBB95A
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu