On Sat, 2012-01-21 at 02:37 +0400, Dmitry V. Levin wrote:
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.
OK, I changed the wording of the manpage a little bit. Is it OK now?
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb