Michael Kerrisk [Sat, 16 Jul 2016 10:32:19 +0000 (12:32 +0200)]
console_ioctl.4: The argument to KDGETMODE is an 'int'
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>
Cownie, James H [Tue, 12 Jul 2016 16:35:43 +0000 (16:35 +0000)]
getauxval.3: Correct AT_HWCAP result description
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).
Michael Kerrisk [Thu, 7 Jul 2016 12:25:12 +0000 (14:25 +0200)]
user_namespaces.7: Clarify details of CAP_SYS_ADMIN and cgroup v1 mounts
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>
perf_event_open.2: Add a note that dyn_size is omitted if size == 0
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.
Michael Kerrisk [Thu, 7 Jul 2016 07:08:45 +0000 (09:08 +0200)]
sysinfo.2: srcfix: change page license
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>
Michael Kerrisk [Wed, 6 Jul 2016 08:10:32 +0000 (10:10 +0200)]
capabilities.7: Note on SECURE_NO_CAP_AMBIENT_RAISE for capabilities-only environment
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>
Michael Kerrisk [Tue, 5 Jul 2016 08:54:44 +0000 (10:54 +0200)]
getitimer.2: Change license to note that page may be modified
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>
Michael Kerrisk [Wed, 22 Jun 2016 19:12:57 +0000 (21:12 +0200)]
ptrace.2: Various fixes after review by Jann Horn
Among other things, Jann pointed out that the commoncap LSM
is always invoked, and Kees Cook pointed out the relevant
kernel code:
===
> BTW, can you point me at the piece(s) of kernel code that show that
> "commoncap" is always invoked in addition to any other LSM that has
> been installed?
It's not entirely obvious, but the bottom of security/commoncap.c shows:
Michael Kerrisk [Wed, 22 Jun 2016 18:41:15 +0000 (20:41 +0200)]
ptrace.2: Clarify the purpose of mentioning the kernel PTRACE_MODE_* constants
The "ptrace access mode" text is about user-space-visible
behavior, but in order to explain that behavior at what I
believe is a sufficient level of detail (e.g., to differentiate
the various types of checks that are performed for various
system calls and pseudofile accesses), one needs (1) to discuss
the MODE flag details as implemented in the kernel, and (2) to
have a shorthand way to refer to the various cases from other
pages. It's not absolutely necessary to name the flags for (1),
but using the flag names is certainly a handy shorthand for (2).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
projects / thirdparty / man-pages.git / log
