From: Matthew Wilcox <matthew@wil.cx>
To: Peter Teoh <htmldeveloper@gmail.com>
Cc: Bryan Henderson <hbryan@us.ibm.com>,
linux-fsdevel@vger.kernel.org,
linux-fsdevel-owner@vger.kernel.org
Subject: Re: "Write once only but read many" filesystem
Date: Tue, 25 Mar 2008 09:22:54 -0600 [thread overview]
Message-ID: <20080325152254.GC16721@parisc-linux.org> (raw)
In-Reply-To: <47E84B94.7090508@gmail.com>
On Tue, Mar 25, 2008 at 08:47:16AM +0800, Peter Teoh wrote:
> Sorry for the confusion. The requirement from upfront is that it is
> ALWAYS WRITE-ONCE only. But many of you will say that it is
> impossible, as it can be written over again via other means. Yes, the
> other means is via "dd", but that will require that you unmount the
> filesystem first, then using dd and hexeditor to modify the
> filesystem. Not sure if I had made myself clear?
You're confused. The kernel cannot prevent root from modifying a block
device while a filesystem is mounted.
Sounds to me like what you really want is a printer. You can't modify
what's been printed.
You could also use a second computer and log to that.
> May be I will describe an auditing scenario to make myself clear - why
> the above does not meet the requirement. First, an arbitrary
> application does something, then the auditing daemon will record it
> down, into a file. Once the file is open for write, it is possible to
> continuosly write to it. But once close, it automatically becomes
> read-only. But permanently no userspace tool can reverse the read-only
> attribute - controlled from the kernel. But while being opened and
> written, it is not possible to move back the file pointer as well - ie,
> once written, is written, not possible to overwrite. Concurrently,
> other files can be opened on the same directory for writing. Can any
> of the abovementioned userspace tool, or existing ext2/3/4 configuration
> can satisfy the above requirement?
Can't be done. root can ptrace the auditing daemon and change what it
wants to write.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2008-03-25 15:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-24 6:45 "Write once only but read many" filesystem Peter Teoh
2008-03-24 16:56 ` Bryan Henderson
2008-03-25 0:47 ` Peter Teoh
2008-03-25 15:22 ` Matthew Wilcox [this message]
2008-03-25 18:42 ` Bryan Henderson
2008-03-25 18:32 ` Bryan Henderson
2008-03-26 2:27 ` Peter Teoh
2008-03-26 16:49 ` Bryan Henderson
-- strict thread matches above, loose matches on Subject: below --
2008-03-14 16:17 filesystem differentiation Peter Teoh
2008-03-14 23:24 ` Andreas Dilger
2008-03-22 4:39 ` "Write once only but read many" filesystem Peter Teoh
[not found] ` <20080322102331.GA19347@logfs.org>
[not found] ` <804dabb00803220752h670757d8o9c1b7fa3696467bc@mail.gmail.com>
[not found] ` <20080322150626.GB19347@logfs.org>
2008-03-22 15:55 ` Peter Teoh
2008-03-22 16:59 ` Jörn Engel
2008-03-24 4:49 ` Scott Lovenberg
2008-03-24 6:35 ` Peter Teoh
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080325152254.GC16721@parisc-linux.org \
--to=matthew@wil.cx \
--cc=hbryan@us.ibm.com \
--cc=htmldeveloper@gmail.com \
--cc=linux-fsdevel-owner@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/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.
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 NNTP newsgroup(s).