--- Al Viro <[email protected]> wrote:
> On Wed, Oct 03, 2007 at 03:23:15PM -0700, Casey Schaufler wrote:
> > 1. Create /moldy at "_"
> > 2. For each label you care about
> > 2a. Create /moldy/<label>
> > 2b. Set the label of /moldy/<label> to <label>
> > 3. ln -s /smack/tmp /tmp
>
> > 1. Create /moldy at "_"
> > 2. For each label you care about
> > 2a. Create /moldy/<label>
> > 2b. Set the label of /moldy/<label> to <label>
> > 3. ln -s /smack/tmp.link /tmp
> 4. mount --bind /moldy /smack/tmp
> or add
> /moldy /smack/tmp none bind,rw 0 2
> to /etc/fstab (same effect as (4))
>
> Compare with your variant; the difference is in one argument of ln(1) and
> one additional line in rc script or /etc/fstab. Sorry, but I don't buy
> the "extra setup complexity" argument at all.
What I'm confused about is how that results in a process labeled "foo"
getting a different /tmp from a process labeled "bar".
I guess I'll have to review your first post.
> > It's the content of a symlink, and that can be just about anything
> > and is not required to point to anything, which is one reason why
> > I made that choice. If you don't have a /tmp, or can't write to the
> > /tmp that exists, or have a /tmp that's a dangling symlink under
> > any circumstances you may have an issue. That's true regardless of
> > the presence or absense of /smack. All of the traditional mechanisms
> > for dealing with /tmp in a chrooted or namespaced environment remain.
>
> It's not about symlink pointing to /smack/<something>; it's about the place
> where /smack/<something> itself points to. And _that_ can bloody well be
> different in different chroots.
Which is completely OK with me.
> Look, if you allow to change where it goes, you certainly allow different
> prefices on different boxen; moreover, admin can change it freely according
> to his layout on given box. OTOH, you _can't_ have it different in different
> chroots and changing it in one will affect all of them. See why that's a
> problem?
Yes, I can see that could be an unexpected behavior.
> > It's in a symlink on the filesystem, and it doesn't have to be an
> > absolute pathname, although since it's a symlink and the semantics
> > for a symlink allow that be be absolute, relative, or dangling I
> > don't see any reason to restrict it from being absolute.
>
> Fixed-contents symlink (with or without variable tail - it's irrelevant
> here) is a bloody wrong tool for that kind of fs for the reasons described
> above.
I do not understand where the concept of Fixed-contents symlink
comes from. Yes, "tmp" is initialized to "/moldy/", but that can
be changed by writing to /smack/links. Please help me understand
the what you mean by fixed-contents symlinks.
> And if you go for "prefix should point to location on the same fs"
> you can trivially configure the rest in userland (one line describing a
> binding), leaving the kernel-side stuff with something like "userland
> can ask for a pair of symlink and directory, having symlink resolve
> to directory + <label>" instead of your "userland can ask for a symlink
> resolving to <prefix> + <label>". And _that_ is chroot-neutral - you don't
> need to do any extra work...
>
> > Could allowing multiple distinct mounts and symlink assignments
> > of /smackfs address those issues?
>
> ... like that one. Leave it to normal userland mechanisms; it's a matter
> of a single line in whatever script you are using to set chroot up and it
> involves _way_ fewer caveats.
>
> That said, Alan's point still stands - if you don't get processes changing
> context back and forth, you don't need anything at all - we already have
> all we need for that kind of setups (and no, selinux is not involved ;-).
Casey Schaufler
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
