From: Wout <git@bliepbliep.net>
To: Ingo Molnar <mingo@elte.hu>
Cc: git@vger.kernel.org
Subject: Re: enforcing DB immutability
Date: Wed, 27 Apr 2005 10:15:23 +0200 [thread overview]
Message-ID: <20050427081523.GA23726@moon> (raw)
In-Reply-To: <20050420074948.GA22620@elte.hu>
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
next prev parent reply other threads:[~2005-04-27 8:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <425C3F12.9070606@zytor.com>
[not found] ` <Pine.LNX.4.58.0504121452330.4501@ppc970.osdl.org>
[not found] ` <20050412224027.GB20821@elte.hu>
[not found] ` <Pine.LNX.4.58.0504121554140.4501@ppc970.osdl.org>
[not found] ` <20050412230027.GA21759@elte.hu>
[not found] ` <20050412230729.GA22179@elte.hu>
[not found] ` <20050413111355.GB13865@elte.hu>
[not found] ` <425D4E1D.4040108@zytor.com>
[not found] ` <20050413165310.GA22428@elte.hu>
[not found] ` <425D4FB1.9040207@zytor.com>
[not found] ` <20050413171052.GA22711@elte.hu>
[not found] ` <Pine.LNX.4.58.0504131027210.4501@ppc970.osdl.org>
[not found] ` <20050413182909.GA25221@elte.hu>
[not found] ` <Pine.LNX.4.58.0504131144160.4501@ppc970.osdl.org>
2005-04-13 20:02 ` Index/hash order Ingo Molnar
2005-04-13 20:07 ` H. Peter Anvin
2005-04-13 20:15 ` Ingo Molnar
2005-04-13 20:18 ` Ingo Molnar
2005-04-13 20:21 ` Ingo Molnar
2005-04-13 20:26 ` Updated base64 patches H. Peter Anvin
2005-04-13 21:04 ` Index/hash order Linus Torvalds
2005-04-20 7:40 ` enforcing DB immutability Ingo Molnar
2005-04-20 7:49 ` Ingo Molnar
2005-04-20 7:53 ` Ingo Molnar
2005-04-20 8:58 ` Chris Wedgwood
2005-04-20 14:57 ` Nick Craig-Wood
2005-04-27 8:15 ` Wout [this message]
2005-04-13 20:15 ` Index/hash order Linus Torvalds
2005-04-13 20:28 ` Baruch Even
[not found] ` <Pine.LNX.4.58.0504131008500.4501@ppc970.osdl.org>
2005-04-13 21:40 ` Florian Weimer
2005-04-13 22:11 ` Linus Torvalds
2005-04-13 22:48 ` Florian Weimer
2005-04-14 7:04 ` Ingo Molnar
2005-04-14 10:50 ` cache-cold repository performance Ingo Molnar
2005-04-20 8:41 enforcing DB immutability linux
2005-04-20 15:57 ` Erik Mouw
2005-04-22 16:10 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050427081523.GA23726@moon \
--to=git@bliepbliep.net \
--cc=git@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).