>
> Looking closer, I think we already have it.
>
> It's called /proc/NNN/root.
>
> Does chroot into /proc/NNN/root cause the chroot'ing process to adopt
> the namespace of NNN? Looking at the code, I think it does.
>
...
>
> So no new system calls are needed. A daemon to hand out per-user
> namespaces (or any other policy) can be written using existing
> kernels, and those namespaces can be joined using chroot.
>
> That's the theory anyway. It's always possible I misread the code (as
> I don't use namespaces and don't have tools handy to try them).
>
I've been thinking about this a bit more...would you even need chroot?
(wouldn't exposing chroot functionality to a user incur additional
security risk? I guess it would be okay as long as you were only
chrooting to one of your other process' roots?)
If you were organized about where the mounts in your private namespace
were done, you could just mount -bind them from
/proc/NNN/root/home/$USER/mnt (or something). That requries a certain
amount of discipline in your mounts (or maybe not -- just diff
/proc/NNN/mounts to see what you are missing and bind the
differences).
-eric
-
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]
