From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Indan Zupancic <indan@nul.nu>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
w@1wt.eu, serue@us.ibm.com
Subject: Re: [PATCH][RFC] Simple tamper-proof device filesystem.
Date: Wed, 9 Jan 2008 17:08:53 -0600 [thread overview]
Message-ID: <20080109230853.GA26627@sergelap.austin.rr.com> (raw)
In-Reply-To: <47176.81.207.0.53.1199887192.squirrel@secure.samage.net>
Quoting Indan Zupancic (indan@nul.nu):
> Hello,
>
> On Wed, January 9, 2008 05:39, Tetsuo Handa wrote:
> > Hello.
> >
> > Indan Zupancic wrote:
> >> I think you focus too much on your way of enforcing filename/attributes
> >> pairs.
> > So?
>
> So that you miss alternatives and don't see the bigger picture.
These emails again are getting really long, but I think the gist of
Indan's suggestion can be concisely summarized:
"To confine process P3 to /dev/hda2 being 'b 3 2', create
/dev/p3, launch P3 in a new mounts namespace, mount --bind
/dev/p3 /dev, exec what you want p3 running, and have
MAC prevent umount /dev/p3."
This is a neat idea, but Tetsuo's rebutall is
"P3 may be legacy code needing to create or delete
/dev/floppy, where -EPERM confuses P3 and prevents
it working correctly."
Indan's idea is interesting and I like it, but is there an answer to
Tetsuo's problem with it?
thanks,
-serge
PS - Indan, you also said in essence "if P3 can be trusted to create
/dev/floppy why can't it be trusted to create /dev/hda1". I trust that,
phrased that way, the question answers itself?
next prev parent reply other threads:[~2008-01-09 23:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-23 14:44 [PATCH][RFC] Simple tamper-proof device filesystem Tetsuo Handa
2007-12-31 20:02 ` Serge E. Hallyn
2008-01-01 2:16 ` Tetsuo Handa
2008-01-06 6:20 ` Tetsuo Handa
2008-01-06 6:26 ` Willy Tarreau
2008-01-06 7:36 ` Tetsuo Handa
2008-01-06 7:45 ` Willy Tarreau
2008-01-06 15:20 ` Tetsuo Handa
2008-01-07 20:37 ` Indan Zupancic
2008-01-08 13:50 ` Tetsuo Handa
2008-01-08 15:47 ` Indan Zupancic
2008-01-09 4:39 ` Tetsuo Handa
2008-01-09 13:59 ` Indan Zupancic
2008-01-09 23:08 ` Serge E. Hallyn [this message]
2008-01-10 1:06 ` Indan Zupancic
2008-01-10 4:57 ` Tetsuo Handa
2008-01-10 23:05 ` Indan Zupancic
2008-01-11 8:46 ` Tetsuo Handa
2008-01-11 12:22 ` Indan Zupancic
2008-01-11 14:05 ` Tetsuo Handa
2008-01-11 14:46 ` Lennart Sorensen
2008-01-07 17:09 ` Valdis.Kletnieks
2008-01-08 13:50 ` Tetsuo Handa
2008-01-09 5:04 ` Valdis.Kletnieks
2008-01-09 6:26 ` Tetsuo Handa
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=20080109230853.GA26627@sergelap.austin.rr.com \
--to=serue@us.ibm.com \
--cc=indan@nul.nu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=w@1wt.eu \
/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).