Carlos O'Donell [Thu, 15 Nov 2018 15:03:41 +0000 (10:03 -0500)]
pthread_rwlockattr_setkind_np.3: Remove bug notes
The notes in pthread_rwlockattr_setkind_np.3 imply there is a bug
in glibc's implementation of PTHREAD_RWLOCK_PREFER_WRITER_NP (a
non-portable constant anyway), but this is not true. The
implementation of PTHREAD_RWLOCK_PREFER_WRITER_NP is made almost
impossible by the POSIX standard requirement that reader locks be
allowed to be recursive, and that requirement makes writer
preference deadlock without an impossibly complex requirement that
we track all reader locks. Therefore the only sensible solution
was to add PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP and
disallow recursive reader locks if you want writer preference.
This patch removes the bug description and documents the current
state and recommendations for glibc. I have also updated bug 7057
with this information, answering Steven Munroe's almost 10 year
old question :-) I hope Steven is enjoying his much earned
retirement.
Should we move the glibc discussion to some footnote? Some libc
may be able to implement the requirement to avoid deadlocks in the
future, but I doubt it (fundamental CS stuff).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Sat, 17 Nov 2018 06:03:07 +0000 (07:03 +0100)]
capabilities.7: Update URL for libcap tarballs
The previous location does not seem to be getting updated.
(For example, at the time of this commit, libcap-2.26
had been out for two months, but was not present at
http://www.kernel.org/pub/linux/libs/security/linux-privs.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Keith Thompson [Fri, 9 Nov 2018 03:55:55 +0000 (04:55 +0100)]
strfry.3: Remove incorrect reference to rand(3)
The strfry(3) function does not use rand(). The original version
from 1995 did, but it was changed to use a different PRNG in glibc
commit 4770745624b7f7f25623f1f10d46a4c4d6aec25c, 1996-12-04.
This C program demonstrates the behavior. By not calling srand(),
it gets the same values for successive calls to rand(), but
strfry() returns a different value each time the program is run.
If strfry() called srand(), it would alter the sequence of numbers
return by rand().
Michael Kerrisk [Wed, 7 Nov 2018 20:41:34 +0000 (21:41 +0100)]
signal.7: Reorder the architectures in the signal number lists
x86 and ARM are the most common architectures, but currently
are in the second subfield in the signal number lists.
Instead, swap that info with subfield 1, so the most
common architectures are first in the list.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Helge Deller [Wed, 7 Nov 2018 06:58:55 +0000 (07:58 +0100)]
signal.7: Add signal numbers for parisc
This patch adds the signal numbers for parisc to the signal(7) man page.
Those parisc-specific values for the various signals are valid since the
Linux kernel upstream commit ("parisc: Reduce SIGRTMIN from 37 to 32 to
behave like other Linux architectures") during development of kernel 3.18:
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1f25df2eff5b25f52c139d3ff31bc883eee9a0ab
Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Helge Deller [Tue, 6 Nov 2018 21:27:23 +0000 (22:27 +0100)]
syscalls.2: parisc Linux does not any longer emulate HP-UX
Initially it was planned that the parisc linux port would natively
support 32-bit HP-UX binaries, but this compatibility was never
reached and finally dropped with Linux kernel 3.14.
With that background, drop parisc from the list of of platforms
which supports it's proprietary operating-system.
Additional notes from mtk:
The most relevant commit from the Linux 3.14 change log was:
parisc: Make EWOULDBLOCK be equal to EAGAIN on parisc
On Linux, only parisc uses a different value for EWOULDBLOCK which
causes a lot of troubles for applications not checking for both values.
Since the hpux compat is long dead, make EWOULDBLOCK behave the same as
all other architectures.
]]
Additional notes from Helge:
The patch above is the initial and most important one with which
we stopped the HP-UX compatibility.
Then, with this commit in kernel 3.18 there is no way back:
"parisc: Reduce SIGRTMIN from 37 to 32 to behave like
other Linux architectures"
commit 1f25df2eff5b25f52c139d3ff31bc883eee9a0ab
And in kernel 4.0 we finally dropped the HP-UX compat layer
from Linux kernel source code with the commit series
"parisc: hpux - Drop support for HP-UX binaries":
commit 04c1614977168fb8f002e2d81f704eeabe0c5ebd
Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Helge Deller [Tue, 6 Nov 2018 21:39:59 +0000 (22:39 +0100)]
syscall.2: parisc needs care with syscall parameters
On parisc one needs to take care of the 32-bit calling conventions
with 64-bit syscall parameters on a 32-bit kernel. So on parisc we
suffer from the same issues like ARM, PowerPC and Xtensa.
Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Mon, 5 Nov 2018 16:24:19 +0000 (17:24 +0100)]
rename.2: Rework list of supported filesystems for RENAME_NOREPLACE
There was probably a little too much detail in
Lukas Werkmeister's patch. Simplify, by removing a few
file systems, and arrange the information as a bulleted
list for easier readability.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
rename.2: Add kernel versions for RENAME_NOREPLACE support
The RENAME_NOREPLACE flag was added with the initial release of the
renameat2 syscall in Linux 3.15, but support for most filesystems was
only added in later versions, and some may still not support it.
Signed-off-by: Lucas Werkmeister <mail@lucaswerkmeister.de> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Elliot Hughes [Wed, 3 Oct 2018 20:00:28 +0000 (13:00 -0700)]
getmntent.3: Clarify that endmntent() should be used rather than fclose()
This doesn't actually matter on any C library I know of --- they
all just do a NULL check and forward to fclose(3). (The actual
mistake I saw was someone not realizing that they had to call
*anything*.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Elliot Hughes [Mon, 1 Oct 2018 17:33:21 +0000 (10:33 -0700)]
ferror.3: Warn about closing the result of fileno()
Since adding checking to Android's bionic for file descriptor
double-closes, we've found that the most common cause of these
bugs is incorrect use of fileno(3). There appears to be a common
misconception that it transfers ownership of the file descriptor
to the caller.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
prctl.2: PR_SET_MM_EXE_FILE may now be used as many times as desired
The original implementation of PR_SET_MM_EXE_FILE only allowed it
to be used once in a process's lifetime. This restriction was
lifted in Linux commit 3fb4afd9a504c2386b8435028d43283216bf588e
("prctl: remove one-shot limitation for changing exe link").
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Joe Lawrence <joe.lawrence@redhat.com> Signed-off-by: Davidlohr Bueso <dbueso@suse.de> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Ian Turner [Thu, 1 Nov 2018 18:44:35 +0000 (14:44 -0400)]
lockf.3: ERRORS: add EINTR
Ian Turner: The exact return calls are at the discretion of the
underlying VFS, but I'm pretty sure that EINTR is a possibility.
Or, if it's not, then the flock() manpage should be amended
accordingly, since the two share the same underlying
implementation.
mtk: lockf(3) is implemented on top of fcntl() locking, so
EINTR is of course a possibility.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Paul Eggert [Wed, 27 Jun 2018 19:52:37 +0000 (12:52 -0700)]
zic.8: Sync from tzdb upstream
Make zic.8 a copy of the upstream tzdb version, except that
the tzdb version's first line is replaced by man-pages
boilerplate, and omit features introduced after 2017b
(the most recent merge to glibc).
This has the following effect:
Document --version, --help.
Document new -v warnings.
Remove -y.
Document that input should be text files, and similar restrictions
on names.
Document negative DST.
Document what is meant by "white space".
Do some minor reformatting.
Use .B for as-is keywords, like commands.
New section "EXTENDED EXAMPLE".
Omit some changes that were made on the man-pages side, notably by
changing some "timezone"s back to the preferred-upstream "time
zone" when talking about traditional time zones as opposed to
POSIX timezone settings. Also, fix some formatting glitches.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Paul Eggert [Wed, 27 Jun 2018 19:52:36 +0000 (12:52 -0700)]
zdump.8: Sync from tzdb upstream
Make zdump.8 a copy of the upstream tzdb version, except that
the tzdb version's first line is replaced by man-pages
boilerplate.
This has the following effect:
Document new options -i, -t, -V.
New section LIMITATIONS.
Do some minor reformatting.
Omit some changes that were made on the man-pages side, notably by
changing some "timezone"s back to the preferred-upstream "time
zone" when talking about traditional time zones as opposed to
POSIX timezone settings. Also, fix some formatting glitches.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Paul Eggert [Wed, 27 Jun 2018 19:52:35 +0000 (12:52 -0700)]
tzfile.5: Sync from tzdb upstream
Make tzfile.5 a copy of the upstream tzdb version, except that
the tzdb version's first line is replaced by man-pages
boilerplate.
This has the following effect:
Do some minor spec fixes, notably about time type 0
and empty TZ strings. Omit some changes that were made on the
man-pages side, notably by changing some "timezone"s back to the
preferred-upstream "time zone" when talking about traditional
time zones as opposed to POSIX timezone settings.
Also, fix some formatting glitches.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Thu, 1 Nov 2018 13:56:24 +0000 (14:56 +0100)]
bpf-helpers.7: Add new man page for eBPF helper functions
eBPF sub-system on Linux can use "helper functions", functions
implemented in the kernel that can be called from within a eBPF program
injected by a user on Linux. The kernel already supports a long list of
such helpers (sixty-seven at this time, new ones are under review).
Therefore, it is proposed to create a new manual page, separate from
bpf(2), to document those helpers for people willing to develop new eBPF
programs.
Additionally, in an effort to keep this documentation in synchronisation
with what is implemented in the kernel, it is further proposed to keep
the documentation itself in the kernel sources, as comments in file
"include/uapi/linux/bpf.h", and to generate the man page from there.
This patch adds the new man page, generated from kernel sources, to the
man-pages repository. For each eBPF helper function, a description of
the helper, of its arguments and of the return value is provided. The
idea is that all future changes for this page should be redirected to
the kernel file "include/uapi/linux/bpf.h", and the modified page
generated from there.
Generating the page itself is a two-step process. First, the
documentation is extracted from include/uapi/linux/bpf.h, and converted
to a RST (reStructuredText-formatted) page, with the relevant script
from Linux sources:
Michael Kerrisk [Thu, 1 Nov 2018 13:32:55 +0000 (14:32 +0100)]
capabilities.7: Correct the description of SECBIT_KEEP_CAPS
This just adds to the point made by Marcus Gelderie's patch. Note
also that SECBIT_KEEP_CAPS provides the same functionality as the
prctl() PR_SET_KEEPCAPS flag, and the prctl(2) manual page has the
correct description of the semantics (i.e., that the flag affects
the treatment of onlt the permitted capability set).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Marcus Gelderie [Wed, 31 Oct 2018 09:35:47 +0000 (10:35 +0100)]
capabilities.7: Add details about SECBIT_KEEP_CAPS
The description of SECBIT_KEEP_CAPS is misleading about the
effects on the effective capabilities of a process during a
switch to nonzero UIDs. The effective set is cleared based on
the effective UID switching to a nonzero value, even if
SECBIT_KEEP_CAPS is set. However, with this bit set, the
effective and permitted sets are not cleared if the real and
saved set-user-ID are set to nonzero values.
This was tested using the following C code and reading the kernel
source at security/commoncap.c: cap_emulate_setxuid.
void print_caps(void) {
cap_t current = cap_get_proc();
if (!current) {
perror("Current caps");
return;
}
char *text = cap_to_text(current, NULL);
if (!text) {
perror("Converting caps to text");
goto free_caps;
}
printf("Capabilities: %s\n", text);
cap_free(text);
free_caps:
cap_free(current);
}
int main(int argc, char **argv) {
puts("[+] Dropping most capabilities to reduce amount of console output...");
set_caps(num_caps, caps);
puts("[+] Dropped capabilities. Starting with these credentials and capabilities:");
puts("[+] Setting all remaining UIDs to nonzero values");
if (setreuid(1000, 1000)) {
perror("Error setting all UIDs to 1000");
return 3;
}
print_caps();
print_creds();
return 0;
}
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Sean Young [Wed, 31 Oct 2018 23:18:00 +0000 (23:18 +0000)]
lirc.4: LIRC_MODE_LIRCCODE has been replaced by LIRC_MODE_SCANCODE
There are no drivers that support LIRC_MODE_LIRCCODE any more;
those drivers were in the kernel staging area, so they were
never part of the mainline kernel.
Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Wed, 31 Oct 2018 07:27:56 +0000 (08:27 +0100)]
user_namespaces.7: Rework terminology describing ownership of nonuser namespaces
Prefer the word "owns" rather than "associated with" when
describing the relationship between user namespaces and non-user
namespaces. The existing text used a mix of the two terms, with
"associated with" being predominant, but to my ear, describing the
relationship as "ownership" is more comprehensible.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Fix broken example code in the vcs.4 man page
- use of wrong variable (attrib, which is uninitialised, instead of s)
- variable ch too narrow
- printing a font char index with %c, as if it were ASCII (it's not)
- removing the high font bit while changing the background colour
- unwarranted assumption of little-endian byte order
Also be friendly and use SEEK_* instead of numbers.
Reported-by: Michael Witten <mfwitten@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
projects / thirdparty / man-pages.git / log
