Starting in Linux 4.11, if the process dumpable attribute is
not 1 and the process resides in a noninitial namespaces that
has valid mappings for UID 0 and GID 0, then the ownership of
/proc/PID/* is made the same as the root IDs of the namespace.
Determined by inspection of fs/proc/base.c
See also the following kernel commit:
commit 68eb94f16227336a5773b83ecfa8290f1d6b78ce
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Tue Jan 3 10:23:11 2017 +1300
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The statement that resetting the dumpable attribute of a process
to 1 causes the ownership of files to revert the process's real
IDs looked suspect. And indeed it is at odds with the code in
fs/proc/base.c::task_dump_owner() (Linux 4.16 sources).
Further verified with a quick test that resetting dumpable to 1
causes the ownership of /proc/PID/* files to revert to the
process's effective IDs. Mea culpa for the original mistake.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The file UID does not come into play when creating a v3
security.capability extended attribute.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make it cleared that all of the library functions
described on this page will use the getcwd() system call
if it is present. (The text previously implied that only
the getcwd() library function made use of the system call,
but looking in the glibc source code shows that all of the
functions make use of a generic implementation (__getcwd())
that uses the system call if it is present.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing text on some of the oddities of the Linux getcwd()
implementation was placed somewhat obtrusively in the DESCRIPTION.
Shift the text to NOTES, and at the same time move the related
discussion of glibc nonconformance to POSIX into BUGS.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In particular, note that it may be difficult for an application
to know about the existence of duplicate file descriptors.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Note a useful performance benefit of EPOLLET: ensuring that
only one of multiple waiters (in epoll_wait()) is woken
up when a file descriptor becomes ready.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The example code currently passes `buflen - 1` to `strncpy`,
however the length parameter to `strncpy` is `size_t`, which is
unsigned. This means that when `buflen` is zero, the cast of `-1`
to unsigned will result in passing `UINT_MAX` as the length.
Obviously, that would be incorrect and could cause `strncpy` to
write well beyond the buffer passed.
The easy solution is to wrap the whole code in the `buflen > 0`
check, rather then just the part of the code that applies the null
terminator.
Signed-off-by: Matthew Kilgore <mattkilgore12@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The nospoof, spoofalert and spoof options as well as the
RESOLV_SPOOF_CHECK environment variable were all removed
from glibc in version 2.25 (with commit
7d68cdaa4f748e87ee921f587ee2d483db624b3d).
Signed-off-by: Nikola Forró <nforro@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since the BSD header has been imported to other C libraries (including
glibc), note that here so people know it isn't BSD-specific.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It's easier to run `./scripts/foo.sh ...` than
`bash ./scripts/foo.sh ...`. Mark them all +x to support that.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In the kernel, the type of the arguments to pkey_alloc() is
"unsigned long" and that's what the page documented until now.
Now that glibc support is added for pkey_alloc(), switch to the
glibc prototype, which uses "unsigned int".
Reported-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>