Re: enforcing DB immutability
On Wed, Apr 20, 2005 at 08:41:15AM -, [EMAIL PROTECTED] wrote: > [A discussion on the git list about how to provide a hardlinked file > that *cannot* me modified by an editor, but must be replaced by > a new copy.] Some time ago there was somebody working on copy-on-write links: once you modify a cow-linked file, the file contents are copied, the file is unlinked and you can safely work on the new file. It has some horrible semantics in that the inode number of the opened file changes, I don't know if applications are or should be aware of that. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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
Re: enforcing DB immutability
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
Re: enforcing DB immutability
On Wed, Apr 20, 2005 at 09:53:20AM +0200, Ingo Molnar wrote: > so the only sensible thing the editor/tool can do when it wants to > change the file is precisely what we want: it will copy the > hardlinked files's contents to a new file, and will replace the old > file with the new file - a copy on write. No accidental corruption > of the DB's contents. editors that have SCM smarts and know about the files different states can do this i really like the way this works under BK btw --- files are RO until i do the magic thing which will do a 'bk edit' and i can then do checkins or similar as needed (this assumes you can do per-file deltas) - 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
Re: enforcing DB immutability
[A discussion on the git list about how to provide a hardlinked file that *cannot* me modified by an editor, but must be replaced by a new copy.] [EMAIL PROTECTED] wrote all of: >>> 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_) > > so the only sensible thing the editor/tool can do when it wants to > change the file is precisely what we want: it will copy the hardlinked > files's contents to a new file, and will replace the old file with the > new file - a copy on write. No accidental corruption of the DB's > contents. This is not a horrible idea, but it touches on another sore point I've worried about for a while. The obvious way to do the above *without* changing anything is just to remove all write permission to the file. But because I'm the owner, some piece of software running with my permissions can just deicde to change the permissions back and modify the file anyway. Good old 7th edition let you give files away, which could have addressed that (chmod a-w; chown phantom_user), but BSD took that ability away to make accounting work. The upshot is that, while separate users keeps malware from harming the *system*, if I run a piece of malware, it can blow away every file I own and make me unhappy. When (notice I'm not saying "if") commercial spyware for Linux becomes common, it can also read every file I own. Unless I have root access, Linux is no safer *for me* than Redmondware! Since I *do* have root access, I often set up sandbox users and try commercial binaries in that environment, but it's a pain and laziness often wins. I want a feature that I can wrap in a script, so that I can run a commercial binary in a nicely restricted enviromment. Or maybe I even want to set up a "personal root" level, and run my normal interactive shells in a slightly restricted enviroment (within which I could make a more-restricted world to run untrusted binaries). Then I could solve the immutable DB issue by having a "setuid" binary that would make checked-in files unwriteable at my normal permission level. Obviously, a fundamental change to the Unix permissions model won't be available to solve short-term problems, but I thought I'd raise the issue to get people thinking about longer-term solutions. - 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
Re: enforcing DB immutability
* 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_) so the only sensible thing the editor/tool can do when it wants to change the file is precisely what we want: it will copy the hardlinked files's contents to a new file, and will replace the old file with the new file - a copy on write. No accidental corruption of the DB's contents. (another in-kernel VFS solution would be to enforce that the files's name always matches the sha1 hash. So if someone edits a DB object it will automatically change its name. But this is complex, probably cannot be done atomically, and brings up other problems as well.) Ingo - 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
Re: enforcing DB immutability
* 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_) i think this might work. (the current chattr +i flag isnt quite what we need though because it works on the inode, and it's also a root-only feature so it puts us back to square one. What would be needed is an immutability flag on hardlinks, settable by unprivileged users.) Ingo - 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
enforcing DB immutability
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Wed, 13 Apr 2005, Ingo Molnar wrote: > > > > well, the 'owned by another user' solution is valid though, and doesnt > > have this particular problem. (We've got a secure multiuser OS, so can > > as well use it to protect the DB against corruption.) > > So now you need root to set up new repositories? No thanks. yeah, it's a bit awkward to protect uncompressed repositories - but it will need some sort of kernel enforcement. (if userspace finds out the DB contains uncompressed blobs, it _will_ try to use them.) (perhaps having an in-kernel GIT-alike versioned filesystem will help - but that brings up the same 'I have to be root' issues. The FS will enforce the true immutability of objects.) 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. Ingo - 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
