The perf_output_sample_ustack in kernel/events/core.c only writes
a single 64 bit word if it can't dump the user registers. From the
current version of the man page, I would have expected two 64 bit
words (one for size, one for dyn_size). Change the man page to
make this behavior explicit.
Reviewed-by: Vince Weaver <vincent.weaver@maine.edu>
The license on the original versoin of this page is troublesome,
because of restrictions imposed by the clause that the page may be
modified "for the purpose of improving Linux or its documentation
efforts".
By now, I have rewritten all except trivial pieces of the page,
and the structure definitions in any case came from kernel header
files. So, I'm relicensing the page to the "verbatim" license.
See https://bugzilla.kernel.org/show_bug.cgi?id=118311
Reported-by: Tom Callaway <tcallawa@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Niki Rahimi, the author of this page, has agreed that it's okay
to change the license to note that the page can be modified.
See https://bugzilla.kernel.org/show_bug.cgi?id=118311
Reported-by: Tom Callaway <tcallawa@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A few months after applying Andy Lutomirski's patch that documented
ambient capabilities, I found myself again asking a question
that I'd already once asked of Any. So, best to be more explicit
in the man page that setting/locking SECBIT_NO_CAP_AMBIENT_RAISE
is not required when using prctl(PR_SET_SECUREBITS) to create
a capabilities-only environment.
This was the 4 Dec 2015 reply from Andy to my question:
> In the capabilities(7) page tehre is the longstanding text:
>
> An application can use the following call to lock itself, and
> all of its descendants, into an environment where the only way
> of gaining capabilities is by executing a program with associ‐
> ated file capabilities:
>
> prctl(PR_SET_SECUREBITS,
> SECBIT_KEEP_CAPS_LOCKED |
> SECBIT_NO_SETUID_FIXUP |
> SECBIT_NO_SETUID_FIXUP_LOCKED |
> SECBIT_NOROOT |
> SECBIT_NOROOT_LOCKED);
>
> As far as I can estimate, no changes are needed here to include
> SECBIT_NO_CAP_AMBIENT_RAISE and SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED
> in the above prctl() call, but could you confirm please?
Correct. I'll probably write up a patch to suggest that doing this is
a poor idea on a conventional distro, though, and I'll explain why. I
suppose than deleting this would be an option, too.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The page as originally written carried text that said the page may
be freely distributed but made no statement about modification.
In the 20+ years since it was first written, the page has in fact
seen repeated, sometimes substantial, modifications, and only a
small portion of the original text remains. One could I suppose
rewrite the last few pieces that remain from the original,
but as the largest contributor to the pages existing text,
I'm just going to relicense it to explicitly note that
modification is permitted. (I presume the failure by the
original author to grant permission to modify was simply an
oversight; certainly, the large number of people who have
changed the page have taken that to be the case.)
Reported-by: Tom Callaway <tcallawa@redhat.com>
See also https://bugzilla.kernel.org/show_bug.cgi?id=118311
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The discussion of RLIMIT_NICE was hidden under the EPERM error,
where it was difficult to find. Place some relevant text in
DESCRIPTION.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See sysdeps/unix/sysv/linux/i386/setfsuid.c in glibc-2.2.1.
(This code is not present in modern glibc anymore.)
Signed-off-by: Jann Horn <jannh@google.com>
Michael Kerrisk