Hello Lucian, On Sun, Oct 24, 2010 at 6:06 PM, Lucian Adrian Grijincu <lucian.grijincu@xxxxxxxxx> wrote: > Hi Michael, > > On Sun, Oct 24, 2010 at 5:35 PM, Michael Kerrisk <mtk.manpages@xxxxxxxxx> wrote: >> +Unshare the network namespace, >> +so that the calling process has a private copy of the >> +network namespace > > That's not exactly right. This is not a private copy of the network > namespace, as that would mean I'd have all devices available in the > new network namespace, but changes done in my private copy will not be > visible to others. This creates a new network namespace from scratch. > You don't have anything from the old network namespace in the new one. > Even the loopback device is new. Thanks for checking this! >> which is not shared with any other process. > > It's not shared with previously existing processes. Child processes > will, by default, inherit the network namespace. > > > How does this one look? Much better. > diff --git a/man2/unshare.2 b/man2/unshare.2 > index 051ebf5..49377c5 100644 > --- a/man2/unshare.2 > +++ b/man2/unshare.2 > @@ -76,6 +76,22 @@ or umask attributes with any other process. > or > .BR umask (2) > .TP > +.BR CLONE_NEWNET " (since Linux 2.6.24) > +This flag has the > +.I same > +effect as the > +.BR clone (2) > +.B CLONE_NEWNET > +flag. > +Unshare the network namespace, > +so that the calling process is moved into a > +new network namespace which is not shared > +with any previous process. > +.BR CLONE_NEWNET > +requires the > +.BR CAP_SYS_ADMIN > +capability. > +.TP > .B CLONE_NEWNS > .\" These flag name are inconsistent: > .\" CLONE_NEWNS does the same thing in clone(), but CLONE_VM, Applied for man-pages-3.30 (but, I changed "previous" to "previously existing"). Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
