From: Al Viro <viro@ftp.linux.org.uk>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: torvalds@osdl.org, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, akpm@osdl.org, paul.moore@hp.com
Subject: Re: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
Date: Wed, 3 Oct 2007 18:52:38 +0100 [thread overview]
Message-ID: <20071003175237.GK8181@ftp.linux.org.uk> (raw)
In-Reply-To: <287091.73995.qm@web36604.mail.mud.yahoo.com>
On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote:
> > what
> > happens if we want it in two chroot jails with different layouts?
>
> As you can only have /smack mounted once, this isn't an issue,
> but it does present an interesting use case that brings the one
> mount limitation into question. I'll add addressing this to the
> short term todo list.
Of course you can mount it more than once. Just bind the sucker and you
are done.
> > I really don't get it; why not simply have something like
> > /smack/tmp.link resolve to tmp/<label> and have userland bind or mount
> > whatever you bloody like on /smack/tmp?
>
> Because you throw "simple" out the window when you require userland
> assistance to perform this function.
Any more than having /tmp replaced with a symlink?
> I'm having some trouble seeing how the 60 lines of code in
> smackfs dealing with symlinks would be improved by your suggestions.
> I certainly don't see how requiring userland intervention would
> do anything but make it bigger and less reliable.
_What_ userland intervention? Mounting stuff under /smack/tmp and not under
your /moldy? Having /tmp replaced with symlink to /smack/tmp.link instead
of replacing it with a symlink to /smack/tmp?
Absolute paths in that kind of thing are _wrong_. You know where the things
are on your fs. You don't know if anything else will be visible, let alone
whether it will be at the same place in all chroots or namespaces. And no,
you _can't_ make sure that fs is visible only in one place. No fs can or
has any business even trying.
next prev parent reply other threads:[~2007-10-03 17:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-03 4:45 [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel Casey Schaufler
2007-10-03 5:12 ` Al Viro
2007-10-03 17:21 ` Casey Schaufler
2007-10-03 17:52 ` Al Viro [this message]
2007-10-03 18:17 ` Alan Cox
2007-10-03 18:17 ` Al Viro
2007-10-03 20:21 ` Casey Schaufler
2007-10-03 20:40 ` Alan Cox
2007-10-03 21:06 ` Casey Schaufler
2007-10-03 19:51 ` Casey Schaufler
2007-10-03 20:57 ` Al Viro
2007-10-03 22:23 ` Casey Schaufler
2007-10-03 22:50 ` Al Viro
2007-10-04 0:42 ` Casey Schaufler
2007-10-03 12:19 ` Paul Moore
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=20071003175237.GK8181@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=akpm@osdl.org \
--cc=casey@schaufler-ca.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul.moore@hp.com \
--cc=torvalds@osdl.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