Re: enforcing DB immutability

From: Ingo Molnar <mingo@elte.hu>
Date: Apr 20, 2005, 07:53 UTC
Message-ID: <20050420075320.GA22676@elte.hu>
In-Reply-To: <20050420074948.GA22620@elte.hu>

* Ingo Molnar <mingo@elte.hu> wrote:

Show 12 quoted lines

> > 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