![]() | ||||||||||
Messages in this thread |
All, 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 | |||||||||
| Last update: 2005-03-22 12:41 [from the cache] ©2003-2008 | ||||||||||