[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071003175237.GK8181@ftp.linux.org.uk>
Date: Wed, 3 Oct 2007 18:52:38 +0100
From: Al Viro <viro@....linux.org.uk>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: torvalds@...l.org, linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, akpm@...l.org, paul.moore@...com
Subject: Re: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists