Document CLONE_NEWPID, CLONE_NEWUSER, and CLONE_NEWNS flags.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Opening a file bind mounted to a /proc/PID/ns/xxx file
also yields a descriptor that can be passed to setns().
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add a sentence to emphasize that these files provide a mapping
based on the user namespace of the file opener.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
These files were introduced in 3.5, not 3.6.
Reported-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Document the user namespace files that report the mapping of UIDs
and GIDs between user namespaces.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See http://bugs.debian.org/758293
drand48() is in current POSIX. It's unclear why SVID 3 would
have marked it obsolete, but that's crufty information that
only serves to pointlessly worry people.
Reported-by: Lorenzo Beretta <lory.fulgi@infinito.it>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Quoting Vincent Lefevre:
In glibc 2.17 and earlier, clock() was implemented on top of
times(2). For improved precision, since glibc 2.18, it is
^^^^^^^^^^^^^^^^^^
implemented on top of clock_gettime(2) (using the
CLOCK_PROCESS_CPUTIME_ID clock).
This looks strange. The user doesn't seek improved precision, but
improved accuracy: if one gets more digits but the value itself is
less accurate (i.e. the error against the ideal value is larger),
this is bad. Perhaps changing "precision" to "accuracy" would be
correct (I assume that the real goal of the change was not just
improved precision, but more importantly the resulting improved
accuracy). I've reported a bug about the glibc documentation:
https://sourceware.org/bugzilla/show_bug.cgi?id=17383
Reported-by: Vincent Lefevre <vincent@vinc17.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The noninteraction of flock(2) and fcntl(2) locks does
not seem to be classical BSD semantics (at least, checking
the 4.4BSD sources suggest that the lock types do interact,
although there have been other systems also where fcntl()
and flock() locks do not interact). So, fix the text
discussing "classical BSD" lock semantics.
Reported-by: J. Bruce Fields <bfields@fieldses.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
POSIX says: "POLLOUT Normal data may be written without
blocking.". This is "may" is misleading, see the POSIX
write page:
Write requests to a pipe or FIFO shall be handled in the
same way as a regular file with the following exceptions:
...
If the O_NONBLOCK flag is clear, a write request may cause
the thread to block, but on normal completion it shall
return nbyte.
...
When attempting to write to a file descriptor (other than a
pipe or FIFO) that supports non-blocking writes and cannot
accept the data immediately:
If the O_NONBLOCK flag is clear, write() shall block the
calling thread until the data can be accepted.
If the O_NONBLOCK flag is set, write() shall not block the
thread. If some data can be written without blocking the
thread, write() shall write what it can and return the
number of bytes written. Otherwise, it shall return -1 and
set errno to [EAGAIN].
The net result is that write() of more than 1 byte on a
socket, pipe or FIFO which is "ready" may block: write()
(unlike read!) will attempt to write the entire buffer and
only return a short write under exceptional circumstances.
Indeed, this is the behaviour we see in Linux:
897626152dhttps://plus.google.com/103188246877163594460/posts/BkTGTMHDFgZ
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It looks like most of the socket options from this man pages
are not defined in <netpacket/packet.h>. They are defined in
<linux/if_packet.h> so we should include that one.
Note from mtk: it looks like <netpacket/packet.h> was based
on some ancient version of <linux/if_packet.h> that has not
been updated. Since linux/if_packet.h is under the "uapi" tree
the proposed patch seems the bext fix.
Signed-off-by: Sorin Dumitru <sdumitru@ixiacom.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Eric W. Biederman