On Wed, Apr 20, 2005 at 09:49:48AM +0200, Ingo Molnar wrote: > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > perhaps having a new 'immutable hardlink' feature in the Linux VFS > > would help? I.e. a hardlink that can only be readonly followed, and > > can be removed, but cannot be chmod-ed to a writeable hardlink. That i > > think would be a large enough barrier for editors/build-tools not to > > play the tricks they already do that makes 'readonly' files virtually > > meaningless. > > immutable hardlinks have the following advantage: a hardlink by design > hides the information where the link comes from. So even if an editor > wanted to play stupid games and override the immutability - it doesnt > know where the DB object is. (sure, it could find it if it wants to, but > that needs real messing around - editors wont do _that_)
This has already been implemented for the linux vserver project. Take a look in the patch here :- http://vserver.13thfloor.at/Experimental/patch-2.6.11.7-vs1.9.5.x5.diff.bz2 (Its not split out, but search for IMMUTABLE and you'll see what I mean) It implements immutable linkage invert, which basically allows people to delete hardlinks to immutable files, but not do anything else to them. It uses another bit out of the attributes to "invert" the immutability of the linkage of immutable files. Its used in the vserver project so that individual vservers (which are basically just fancy chroots) can share libraries, binaries and hence memory, can't muck each other up, but can upgrade their libs/binaries. -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
