linux-kernel October 2007 archive
Main Archive Page > Month Archives  > linux-kernel archives
linux-kernel: Re: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simp

Re: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel

From: Al Viro <viro_at_nospam>
Date: Wed Oct 03 2007 - 17:52:38 GMT
To: Casey Schaufler <casey@schaufler-ca.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.
-
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html