[EMAIL PROTECTED] (Sam Vilain) writes:
> The following patch, to vservers.functions in the util-vserver
> distribution, will do something of a `namespace cleanup' in lieu of
> the rework to the vserver startup and mount cleanup process that
> Enrico has planned (I'm told).
Currently there are two conflicting requirements:
(a) 'vserver ... enter' and operating from the outside in the vserver, and
(b) cleaning /proc/mounts
I am tending to keep (a) but it was told that people *require* (b).
There is an experimental 'UV_NAMESPACE_AFTER_CHROOT' branch in CVS which
enables (b). Basically, it calls vc_set_namespace(2) after chroot(2) and
kernel makes some cleanups then. As expected, this breaks (a), because
after
| vnamespace --enter ...
your host-context process will be chrooted into the (hostile) vserver-dir.
Some explanations about the current (a) method:
1. a new namespace is created
2. all extra-mountings will be executed (from the vserver-fstab)
3. 'mount --rbind /vservers/... /' will be executed
4. the context will be created
5. the chroot will be entered and the init-process be executed
There is an alternative approach implementing (b): doing 4. before 2.
which would tag the mountpoints in 2. and would allow a later cleanup of
all untagged ones. Since scripts are involved, this approach requires
multiple, parallel processes whose synchronization can be done by bash
in an ugly way only. Therefore, a binary implementation of vserver.start
is planned. But this will not solve the conflict between (a) and (b).
Back to (a): After 3. your /proc/mounts looks like
| / ## 1
| /dev/pts
| /usr
| /var
| / ## 2
| /tmp
| /dev/pts
The last entries (after #2) are from the '--rbind'. The current process's
'/' (/proc/self/root) is still the '/' #1 (you never changed it). Therefore,
every 'cd /' or 'cat /blahblub' will operate in the original filesystem.
After executing the chroot('/vservers/...'), the '/' #1 will be
disassociated (you do not have any reference on it anymore), but it
still exists somewhere. Now, you lost any reference-point and operate in
the most recent filesystem-hierarchy which is this behind '/' #2.
Therefore, the 'chroot("..')' escape tricks will not work: '/' #2 is
your '/' and you can not go before it. Nevertheless, with help from the
outside you can exchange FDs and go back into #1. Removing unneeded
mountpoints from the namespace as suggested would remove some entries
between #1 and #2 also. But it would not protect against the FD exchange
trick completely (e.g. /vservers/... filesystems are usually on the same
device and FD exchanging would work there).
I really do not know how to solve the conflict between (a) and (b):
currently you can have one but not both features.
Enrico
_______________________________________________
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
