Your message dated Fri, 06 Nov 2015 11:24:32 +0000
with message-id <[email protected]>
and subject line Bug#799654: fixed in mininet 2.2.1-2
has caused the Debian Bug report #799654,
regarding mininet: mnexec should make mount namespace private
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
799654: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799654
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: mininet
Version: 2.2.1-1
Severity: normal

Dear Maintainer,

mnexec, which is used to spawn mininet's node processes in a different 
mount and network namespace, does not correctly cope with systemd's 
default of making the root mount namespace hierarchy shared (see #739593 
for details).

In particular, mounts happening inside the node namespaces are visible 
from the rest of the system as well, which breaks things if e.g. one 
wants to mount a tmpfs under /run/network using privateDirs, especially 
since the node processes share the same root filesystem with the rest of 
the system. Also, as a result of using a shared mount hierarchy, the 
/sys mounts performed by mnexec on startup are not cleaned up on mininet 
termination and slowly pile up after successive mininet executions.

The attached patch makes sure that the whole filesystem hierarchy is 
marked as private in the new namespace, i.e. new mounts from the root 
system will not propagate to the node namespaces and mounts performed in 
the node namespaces will remain invisible to the rest of the system and 
will be cleaned up on node termination.

Regards,
Apollon

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (90, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mininet depends on:
ii  cgroup-bin            0.41-6
ii  iperf                 2.0.5+dfsg1-2
ii  libc6                 2.19-18
ii  openvswitch-switch    2.3.0+git20140819-3
ii  python                2.7.9-1
ii  python-pkg-resources  17.0-1
ii  socat                 1.7.3.0-1
ii  telnet                0.17-40

mininet recommends no packages.

mininet suggests no packages.

-- debconf-show failed
Author: Apollon Oikonomopoulos <[email protected]>
Subject: mnexec: properly setup the mount namespace
 Systemd's default is to mark the root mount as shared and it is inherited as
 such by the new mount namespace. This means that any mounts performed in the
 new namespace will be visible by the rest of the system, breaking privateDirs.
 .
 To restore a more sane behaviour, we explicitly mark all mounts recursively as
 private, meaning that we will no longer see new mounts from the root
 namespace, and our mounts will also not propagate to the rest of the system.
Last-Update: 2015-09-21
--- a/mnexec.c
+++ b/mnexec.c
@@ -130,6 +130,15 @@
                 perror("unshare");
                 return 1;
             }
+
+           /* Mark our whole hierarchy recursively as private, so that our
+            * mounts do not propagate to other processes.
+            */
+           if (mount("none", "/", NULL, MS_REC|MS_PRIVATE, NULL) == -1) {
+               perror("remount");
+               return 1;
+           }
+
             /* mount sysfs to pick up the new network namespace */
             if (mount("sysfs", "/sys", "sysfs", MS_MGC_VAL, NULL) == -1) {
                 perror("mount");

--- End Message ---
--- Begin Message ---
Source: mininet
Source-Version: 2.2.1-2

We believe that the bug you reported is fixed in the latest version of
mininet, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Tomasz Buchert <[email protected]> (supplier of updated mininet package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Fri, 06 Nov 2015 11:39:22 +0100
Source: mininet
Binary: mininet
Architecture: source amd64
Version: 2.2.1-2
Distribution: unstable
Urgency: medium
Maintainer: Dariusz Dwornikowski <[email protected]>
Changed-By: Tomasz Buchert <[email protected]>
Description:
 mininet    - process-based network emulator
Closes: 799654
Changes:
 mininet (2.2.1-2) unstable; urgency=medium
 .
   * Make container mounts private (Closes: #799654)
   * Switch the build process to pybuild
Checksums-Sha1:
 27b77aa2d8d038a06665d6beeeb32356dca22a14 1951 mininet_2.2.1-2.dsc
 4654ab5d43f1a37415e992d11490a17243491e7e 3612 mininet_2.2.1-2.debian.tar.xz
 3c3d09293519d83b5bc0d51d717f8090c9d1844d 176528 mininet_2.2.1-2_amd64.deb
Checksums-Sha256:
 774120aa6b403270fc8a32feab1ce390e7cdeeab7e7069e2c35959dd56919cda 1951 
mininet_2.2.1-2.dsc
 c9aae9b7a36dd14ad575883fdf16b9f9fe3b34feab956fa09ecf02bcb14d9234 3612 
mininet_2.2.1-2.debian.tar.xz
 097c71bdd9d03d600099170700930a50c0f44750f65be664471aa10009028c4a 176528 
mininet_2.2.1-2_amd64.deb
Files:
 25a5ac39245c1eeda8dac1d603f9f535 1951 net optional mininet_2.2.1-2.dsc
 881b93e10d100db6cc633139b4bc0c75 3612 net optional 
mininet_2.2.1-2.debian.tar.xz
 e144d263f652fc5ff622d48a8a04e540 176528 net optional mininet_2.2.1-2_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJWPIQMAAoJEJ+5JicksX0pXh0P/ijjyPrRvgghsEnYF9S+l6nz
FKS0ZnOwXl2gWWYkHLFbGVDr+UBvTl9e2F+PB3ofcme03p8xoJnX/VmRoZygDkM+
hQBG5lCGRdddMnI3u4hKlK/QZ8MbwHpmABA0tIDwH7QvS6pSQG++CvIB/EVc9oq2
AqARv59Ds7ZX6h3GxqCHbWTN+PO60CJPayZBc8f/3X3a2kY3TEfT/MgIIu/wj5MB
w3iCKC1Jp9dEdXHz6DaUPuWskv9bICnzFdakHQ1QYrTKWxAt6ZCFW5swCO5E1msy
I/fof10T11uo9i8ed5haAycZ0qmX5bQ/fyrOphQuB26s0ktSlRMqBNT9ElnDUwhJ
G83+pV2J6yhiHlG1K1y5dvg7ehpV1+DGcSFa2AiEI027H/cvBgHLe61b3/+86mDB
WHNpq/uF5ora+DvcOazAAzHRYaZyo6DGmXQDJOMu7mmmMIsnU0XI9qTeDRCMY95V
YTtgDvTsvqmzcQIt6mQVNKC+QRbvnkZl2YweLH2q3I0ZoUSrsarmz8aXX5Sc4J3o
QbRux2N8fAVtEzk7H8+ktDkU2xqjx4JZvLvLuYqez+tBO3SFFchNkMKWZZOCAqiL
FGrWm9HZWtVUKn2RnE15v2HXkRYs7V8qsfYjHHp8fDq3S7m5etC7KLiYP27VDJPO
22zWZA3jO+JE06TpuJrM
=QVo2
-----END PGP SIGNATURE-----

--- End Message ---

Reply via email to