On 06/05/2015 07:11 AM, Andreas Henriksson wrote:
Hello James Long.
Thanks for the additional feedback you provided.
On Fri, Jun 05, 2015 at 07:00:22AM -0800, James Long wrote:
[...]
Yes, I must be missing something here. I thought that 'mount
--make-rprivate' would restore the previous behavior (man page suggests
rprivate rather than private):
[...]
Before or after using "mount --make-rprivate /" you can check what
the current setting is using "findmnt -o TARGET,PROPAGATION".
After doing the mount, "findmnt -o TARGET,PROPAGATION" reports
└─/mnt private
and yet other users and processes can still see and use it.
If you're using unshare(2) and know you want the mounts private,
then always pass the private flag as done by the commit to
util-linux/unshare(1) previously mentioned does. (But I'm not
going to consider unshare(2), because that's not part of the
util-linux package which you filed the bug against.)
My mistake. If this really is an unshare(2) problem, I will file the bug
in the appropriate venue.
Unless additional useful information comes in, I'll probably
go with claiming this bug is fixed in 2.27.x once released,
which will contain the commit that makes unshare less confusing.
For stable/jessie you might very well have to settle with
manually handling the propagation flags before assuming
anything about unshared mount namespaces. (And in your own
code you'll have to stop assuming any default settings and
just set whatever you need.)
Regards,
Andreas Henriksson
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
