{"thread":{"id":"168","subject":"Re: enforcing DB immutability","startedAt":"2005-04-20T07:55:28Z","lastAt":"2005-04-22T16:10:41Z","messageCount":3,"participants":["linux@horizon.com","Erik Mouw","Bill Davidsen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"956","messageId":"20050420084115.2699.qmail@science.horizon.com","threadId":"168","inReplyTo":null,"subject":"Re: enforcing DB immutability","fromName":"","fromEmail":"linux@horizon.com","sentAt":null,"receivedAt":"2005-04-20T07:55:28Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"[A discussion on the git list about how to provide a hardlinked file\nthat *cannot* me modified by an editor, but must be replaced by\na new copy.]\n\nmingo@elte.hu wrote all of:\n>>> perhaps having a new 'immutable hardlink' feature in the Linux VFS \n>>> would help? I.e. a hardlink that can only be readonly followed, and \n>>> can be removed, but cannot be chmod-ed to a writeable hardlink. That i \n>>> think would be a large enough barrier for editors/build-tools not to \n>>> play the tricks they already do that makes 'readonly' files virtually \n>>> meaningless.\n>> \n>> immutable hardlinks have the following advantage: a hardlink by design \n>> hides the information where the link comes from. So even if an editor \n>> wanted to play stupid games and override the immutability - it doesnt \n>> know where the DB object is. (sure, it could find it if it wants to, \n>> but that needs real messing around - editors wont do _that_)\n>\n> so the only sensible thing the editor/tool can do when it wants to \n> change the file is precisely what we want: it will copy the hardlinked \n> files's contents to a new file, and will replace the old file with the \n> new file - a copy on write. No accidental corruption of the DB's \n> contents.\n\nThis is not a horrible idea, but it touches on another sore point I've\nworried about for a while.\n\nThe obvious way to do the above *without* changing anything is just to\nremove all write permission to the file.  But because I'm the owner, some\npiece of software running with my permissions can just deicde to change\nthe permissions back and modify the file anyway.  Good old 7th edition\nlet you give files away, which could have addressed that (chmod a-w; chown\nphantom_user), but BSD took that ability away to make accounting work.\n\nThe upshot is that, while separate users keeps malware from harming the\n*system*, if I run a piece of malware, it can blow away every file I\nown and make me unhappy.  When (notice I'm not saying \"if\") commercial\nspyware for Linux becomes common, it can also read every file I own.\n\nUnless I have root access, Linux is no safer *for me* than Redmondware!\n\nSince I *do* have root access, I often set up sandbox users and try\ncommercial binaries in that environment, but it's a pain and laziness\noften wins.  I want a feature that I can wrap in a script, so that I\ncan run a commercial binary in a nicely restricted enviromment.\n\nOr maybe I even want to set up a \"personal root\" level, and run\nmy normal interactive shells in a slightly restricted enviroment\n(within which I could make a more-restricted world to run untrusted\nbinaries).  Then I could solve the immutable DB issue by having a\n\"setuid\" binary that would make checked-in files unwriteable at my\nnormal permission level.\n\nObviously, a fundamental change to the Unix permissions model won't\nbe available to solve short-term problems, but I thought I'd raise\nthe issue to get people thinking about longer-term solutions.\n"},{"id":"993","messageId":"20050420155723.GC27307@harddisk-recovery.com","threadId":"168","inReplyTo":"20050420084115.2699.qmail@science.horizon.com","subject":"Re: enforcing DB immutability","fromName":"Erik Mouw","fromEmail":"erik@harddisk-recovery.com","sentAt":"2005-04-20T15:57:23Z","receivedAt":"2005-04-20T15:57:23Z","isPatch":false,"sender":{"key":"erik@harddisk-recovery.com","avatar":null},"body":"On Wed, Apr 20, 2005 at 08:41:15AM -0000, linux@horizon.com wrote:\n> [A discussion on the git list about how to provide a hardlinked file\n> that *cannot* me modified by an editor, but must be replaced by\n> a new copy.]\n\nSome time ago there was somebody working on copy-on-write links: once\nyou modify a cow-linked file, the file contents are copied, the file is\nunlinked and you can safely work on the new file. It has some horrible\nsemantics in that the inode number of the opened file changes, I don't\nknow if applications are or should be aware of that.\n\n\nErik\n\n-- \n+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --\n| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands\n"},{"id":"1286","messageId":"42692201.2000300@tmr.com","threadId":"168","inReplyTo":"20050420084115.2699.qmail@science.horizon.com","subject":"Re: enforcing DB immutability","fromName":"Bill Davidsen","fromEmail":"davidsen@tmr.com","sentAt":"2005-04-22T16:10:41Z","receivedAt":"2005-04-22T16:10:41Z","isPatch":false,"sender":{"key":"davidsen@tmr.com","avatar":null},"body":"linux@horizon.com wrote:\n> [A discussion on the git list about how to provide a hardlinked file\n> that *cannot* me modified by an editor, but must be replaced by\n> a new copy.]\n> \n> mingo@elte.hu wrote all of:\n> \n>>>>perhaps having a new 'immutable hardlink' feature in the Linux VFS \n>>>>would help? I.e. a hardlink that can only be readonly followed, and \n>>>>can be removed, but cannot be chmod-ed to a writeable hardlink. That i \n>>>>think would be a large enough barrier for editors/build-tools not to \n>>>>play the tricks they already do that makes 'readonly' files virtually \n>>>>meaningless.\n>>>\n>>>immutable hardlinks have the following advantage: a hardlink by design \n>>>hides the information where the link comes from. So even if an editor \n>>>wanted to play stupid games and override the immutability - it doesnt \n>>>know where the DB object is. (sure, it could find it if it wants to, \n>>>but that needs real messing around - editors wont do _that_)\n>>\n>>so the only sensible thing the editor/tool can do when it wants to \n>>change the file is precisely what we want: it will copy the hardlinked \n>>files's contents to a new file, and will replace the old file with the \n>>new file - a copy on write. No accidental corruption of the DB's \n>>contents.\n> \n> \n> This is not a horrible idea, but it touches on another sore point I've\n> worried about for a while.\n> \n> The obvious way to do the above *without* changing anything is just to\n> remove all write permission to the file.  But because I'm the owner, some\n> piece of software running with my permissions can just deicde to change\n> the permissions back and modify the file anyway.  Good old 7th edition\n> let you give files away, which could have addressed that (chmod a-w; chown\n> phantom_user), but BSD took that ability away to make accounting work.\n> \n> The upshot is that, while separate users keeps malware from harming the\n> *system*, if I run a piece of malware, it can blow away every file I\n> own and make me unhappy.  When (notice I'm not saying \"if\") commercial\n> spyware for Linux becomes common, it can also read every file I own.\n> \n> Unless I have root access, Linux is no safer *for me* than Redmondware!\n> \n> Since I *do* have root access, I often set up sandbox users and try\n> commercial binaries in that environment, but it's a pain and laziness\n> often wins.  I want a feature that I can wrap in a script, so that I\n> can run a commercial binary in a nicely restricted enviromment.\n> \n> Or maybe I even want to set up a \"personal root\" level, and run\n> my normal interactive shells in a slightly restricted enviroment\n> (within which I could make a more-restricted world to run untrusted\n> binaries).  Then I could solve the immutable DB issue by having a\n> \"setuid\" binary that would make checked-in files unwriteable at my\n> normal permission level.\n> \n> Obviously, a fundamental change to the Unix permissions model won't\n> be available to solve short-term problems, but I thought I'd raise\n> the issue to get people thinking about longer-term solutions.\n\nchattr +i file\n\nBut the real problem is that you expect your editor to be smart enough \nto diddle permissions (some aren't) or create a new file (some aren't \nthat either).\n\nIt sounds as if you're kind of using the wrong tool here, frankly.\n\nYou also don't understand hard links, they don't hide anything, the \ninode number is there, which is exactly as much information as is in the \noriginal link. And they are lots safer, since you can't wind up with \nthem pointing to a non-existent file, get them in circular loops, etc. \nOkay, YOU probably wouldn't, but believe me semi-competent users \nregularly these things.\n\n-- \n    -bill davidsen (davidsen@tmr.com)\n\"The secret to procrastination is to put things off until the\n  last possible moment - but no longer\"  -me\n"}]}