Re: enforcing DB immutability

Re: enforcing DB immutability

[linux]

[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.]

mingo@elte.hu 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.

Re: enforcing DB immutability

[Erik Mouw]

On Wed, Apr 20, 2005 at 08:41:15AM -0000, linux@horizon.com 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

Re: enforcing DB immutability

[Bill Davidsen]

linux@horizon.com 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.]
> 
> mingo@elte.hu 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.

chattr +i file

But the real problem is that you expect your editor to be smart enough 
to diddle permissions (some aren't) or create a new file (some aren't 
that either).

It sounds as if you're kind of using the wrong tool here, frankly.

You also don't understand hard links, they don't hide anything, the 
inode number is there, which is exactly as much information as is in the 
original link. And they are lots safer, since you can't wind up with 
them pointing to a non-existent file, get them in circular loops, etc. 
Okay, YOU probably wouldn't, but believe me semi-competent users 
regularly these things.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Index/hash order

[Ingo Molnar]

* Linus Torvalds <torvalds@osdl.org> wrote:

> > with a plaintext repository we could do the 'hardlink trick' (which 
> > brings in other manageability problems and limitations but is at least a 
> > partially good idea), which would make the working tree and the 
> > repository share the same inode in most cases.

> However, the real issue is that you're really asking for trouble. 
> There are tons of tools that modify files without breaking the 
> hardlink. Even some editors do. So you just use the wrong tool on the 
> tree by mistake, and not only is your archive corrupt, you've 
> corrupted all other archives that might have shared the same object 
> directory.

that's what i loosely meant under 'manageability problems'.

I mentioned one solution earlier: to make the repository object an 
immutable file (the +i flag on the inode) - it really wants to be 
immutable after all. That would solve a whole range of 'accidental 
corruption' issues.

Another solution (suggested by Christer Weinigel) was to enforce 
immutability by making it owned by another user/group (git:git or 
whatever).

but having a binary compressed format is 'soft immutability', done 
cleverly.

	Ingo

Re: Index/hash order

[H. Peter Anvin]

Ingo Molnar wrote:
> 
> that's what i loosely meant under 'manageability problems'.
> 
> I mentioned one solution earlier: to make the repository object an 
> immutable file (the +i flag on the inode) - it really wants to be 
> immutable after all. That would solve a whole range of 'accidental 
> corruption' issues.
> 

I think abusing the immutable bit quickly will decend into the same 
rathole which makes u-w often useless.  u-w will actually be preserved 
by more tools -- simply because they know about it -- than +i.

Either which way, it feels to me that this idea has already been ruled 
out, so it's probably pointless to keep debating just exactly what we're 
not actually going to do.

	-hpa

Re: Index/hash order

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> >that's what i loosely meant under 'manageability problems'.
> >
> >I mentioned one solution earlier: to make the repository object an 
> >immutable file (the +i flag on the inode) - it really wants to be 
> >immutable after all. That would solve a whole range of 'accidental 
> >corruption' issues.
> >
> 
> I think abusing the immutable bit quickly will decend into the same 
> rathole which makes u-w often useless.  u-w will actually be preserved 
> by more tools -- simply because they know about it -- than +i.

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

> Either which way, it feels to me that this idea has already been ruled 
> out, so it's probably pointless to keep debating just exactly what 
> we're not actually going to do.

(even if it sounds stupid, i keep discussing decisions that are done for 
reasons i cannot fully agree with (yet), even if i happen to agree with 
the net decision. It's all technological arguments, so it's not like 
there's anything fuzzy about any of these issues.)

	Ingo

Re: Index/hash order

[Linus Torvalds]

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.

		Linus

enforcing DB immutability

[Ingo Molnar]

* Linus Torvalds <torvalds@osdl.org> 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

Re: enforcing DB immutability

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> 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

Re: enforcing DB immutability

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> 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

Re: enforcing DB immutability

[Chris Wedgwood]

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)

Re: enforcing DB immutability

[Nick Craig-Wood]

On Wed, Apr 20, 2005 at 09:49:48AM +0200, Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> 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 <nick@craig-wood.com> -- http://www.craig-wood.com/nick

Re: enforcing DB immutability

[Wout]

On Wed, Apr 20, 2005 at 09:49:48AM +0200, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@elte.hu> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Slightly off-topic for this list. Apologies to those offended.

Would a filesystem that allows sharing of blocks between inodes
be useful here? Each block would need a reference count (refco).
Writing a block would be impossible once refco > 1. If someone
attempts to write to such a block, a new block is allocated for
that particular inode and the refco of the original is decreased.

Next to this there would have to be a clone_file() function:
    clone_file(src-file, dst-file, mode)

This function would create file dst-file with a new inode that
references the blocks belonging to src-file (increasing the
blocks' reference counts). The owner/group of dst-file are the
caller, not the owner of src-file.

Things to check for are:
    - read permissions for src-file
    - write permissions for dst-file
    - are src-file and dst-file in the same filesystem (if not,
      one could implement copy)
    - ...?


Suppose I have a file foo:

    foo -> inode1(blk1[1], blk2[1], blk3[1], blk4[1])

The [n] value on the blocks is the reference count.
I now call clone_file("foo", "bar", 0644):

    foo -> inode1(blk1[2], blk2[2], blk3[2], blk4[2])
    bar -> inode2(blk1[2], blk2[2], blk3[2], blk4[2])

Next I modify blk2 of bar (write):

    foo -> inode1(blk1[2], blk2[1], blk3[2], blk4[2])
    bar -> inode2(blk1[2], blk5[1], blk3[2], blk4[2])


I see the following uses:

- Checking out a tree of (uncompressed) files with git could be
  done using the clone_file() call on each file. This means no
  extra disk space is used unless files are edited later.

- Easy way to freeze files for backups. A database (mysql, ...)
  could bring its files into an acceptable state, call clone_file()
  on them and proceed with its work.

- It could be used to protect user files from external tampering.
  Someone mentioned the problems with malware killing his files.
  The impact of this could be reduced by having a script that did
  a clone_file() on everything as root periodically. If files are
  deleted, root would have a backup.


Notes:

- Small changes to files would probably cause all the blocks to
  be copied as programs (editors) usually write out the complete
  file.

- I don't know anything about implementing filesystems so all of
  the above could be complete nonsense.

- The idea isn't mine, I've come across this before under the name
  of 'snapshot filesystems' and I think it was patented. I've never
  heard of anyone doing this for individual files though.

Wout