On Fri, Jan 20, 2012 at 04:54:10PM +0100, Tomas Mraz wrote:
This is a fix for the problem recently reported in trac. It is not a
perfect solution as in case the root user account is polyinstantiated as
well it will not be possible to mainpulate the mounts in the parent
namespace. However a perfect fix is not possible without changes in
kernel mount() syscall implementation and the current problem is much
worse.
--- a/modules/pam_namespace/pam_namespace.8.xml
+++ b/modules/pam_namespace/pam_namespace.8.xml
@@ -246,12 +246,17 @@
This option can be used on systems where the / mount point or
its submounts are made shared (for example with a
<command>mount --make-rshared /</command> command).
- The module will make the polyinstantiated directory mount points
- private. Normally the pam_namespace will try to detect the
+ The module will mark the whole directory tree with the MS_SLAVE flag.
+ Normally the pam_namespace will try to detect the
shared / mount point and make the polyinstantiated directories
private automatically. This option has to be used just when
only a subtree is shared and / is not.
</para>
No MS_* constants were used in this manual before, so maybe it would be
wise to avoid starting this practice now. Also, since the option is called
"mount_private", a statement that it will mark the root directory not as a
private mount point but as a slave mount point is somewhat confusing.
I had to read
http://bugzilla.redhat.com/755216 to understand why we have
to mount the root directory as a slave mount point to achieve the effect
of private polyinstantiated mount points.
+ <para>
+ Note that mounts and unmounts done in the private namespace will not
+ affect the parent namespace if this option is used or when the
+ shared / mount point is autodetected.
+ </para>
</listitem>
</varlistentry>
--
ldv