As reported by Chris:i
The manual entry for KDGETMODE specifies "argp points to
a long which is set to one of the above values." At least
on x86_64-bit Fedora24, the text should probably specify
argp is an int (32-bit), rather than a long (64-bit).
[To verify:]
Open a file descriptor to the local console, and execute
some code like the following:
long arg = -1;
if (-1 == ioctl(fd, KDGETMODE, &arg)) { return -1; }
printf("KDGETMODE: 0x%lx\n", arg);
Now try this version:
int arg = -1;
if (-1 == ioctl(fd, KDGETMODE, &arg)) { return -1; }
printf("KDGETMODE: 0x%x\n", arg);
Result:
The first version gives this result:
KDGETMODE: 0xffffffff00000001
The second version gives this result:
KDGETMODE: 0x1
Reading the kernel source confirms this point.
Reported-by: Chris Gassib <position0x45@hotmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The getauxval(3) man page describes the result for AT_HWCAP as
"A pointer to a multibyte mask of bits", however the actual value
returned is not a pointer, but simply the first 32 bits of the
capabilities mask.
This can be observed directly. Note the value shown for AT_HWCAP
is a 32 bit value that is not a pointer (see AT_PHDR or AT_RANDOM
for how pointers are shown).
% LD_SHOW_AUXV=1 cat < /dev/null
AT_SYSINFO_EHDR: 0x7fffe89fe000
AT_HWCAP: bfebfbff
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x400040
AT_PHENT: 56
AT_PHNUM: 9
AT_BASE: 0x0
AT_FLAGS: 0x0
AT_ENTRY: 0x402634
AT_UID: 515
AT_EUID: 515
AT_GID: 114
AT_EGID: 114
AT_SECURE: 0
AT_RANDOM: 0x7fffe8917be9
AT_EXECFN: /usr/bin/cat
AT_PLATFORM: x86_64
With respect to cgroups version 1, CAP_SYS_ADMIN in the user
namespace allows only *named* hierarchies to be mounted (and
not hierarchies that have a controller).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
strxfrm() and strncpy() are not precisely equivalent in the
POSIX locale, so this NOTES section was not really correct.
See https://bugzilla.kernel.org/show_bug.cgi?id=104221
Reported-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add some more details for Section 1 and 8 formatting.
Separate out formatting discussion into commands, functions,
and "general".
In part triggered by https://bugzilla.kernel.org/show_bug.cgi?id=121211
Reported-by: Josh Triplett <josh@kernel.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>