On 06/05/2015 06:30 AM, Phil Susi wrote:
On 6/5/2015 9:23 AM, James Long wrote:
Hi Andreas,
My problem is actually with unshare(2), rather than unshare(1). Is
there an equivalent patch for unshare(2)?
I don't think you understood the upstream patch. The idea is that after
unshare(2), calls to mount(2) have the option causing the mount to show
up in other namespaces or not. You seem to have an expectation mismatch
in this regard. If you do not want it to show up in the other
namespace, then you need to mount --make-private.
In other words, this is not a bug in unshare ( 1 or 2 ).
The man page in jessie for mount(2) states
"A process can obtain a private mount namespace if: it was created
using the clone(2) CLONE_NEWNS flag, in which case its new namespace is
initialized to be a copy of the namespace of the process that
called clone(2); or it calls unshare(2) with the CLONE_NEWNS flag, which
causes the caller's mount namespace to obtain a private copy of the
namespace that it was previously sharing with other processes, so that
future mounts and unmounts by the caller are invisible to other
processes (except child processes that the caller subsequently creates)
and vice versa."
Does the man page need to be updated?
Thanks,
Jim
--
James Long
Information Systems Manager
International Arctic Research Center
University of Alaska Fairbanks
jlong15 at alaska.edu
(907) 474-2440
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
