Michael Kerrisk [Wed, 27 Feb 2019 14:19:05 +0000 (15:19 +0100)]
mdoc.7, mdoc.samples.7: Remove these pages
groff_mdoc(7) from the groff project provides a better
equivalent of mdoc.samples(7) and the 'mandoc' project
provides a better mdoc(7). And nowadays, there are virtually
no pages in "man-pages" that use mdoc markup.
So, drop these pages.
From a conversation on linux-man with Ingo Schwarz:
[[
Subject: Re: [groff] [PATCH] man7/mdoc_samples.7: srcfix: Avoid a warning about a wrong section
Date: Wed, 27 Feb 2019 15:28:19 +0100
> The two actual problems are both within the Linux man-pages project,
> not within groff:
>
> 1. While back in the early 1990ies, Cynthia Livingston's
> mdoc.samples(7) manual page was an important document and the
> de-facto language definition of the mdoc(7) language, it has
> been outdated for a long time now. The current groff_mdoc(7)
> manual page is based on it but contains large numbers of important
> improvements by Werner Lemberg and others. As an alternative
> language definition that is slightly more concise without being
> less precise and complete, the mdoc(7) manual page is available
> from the mandoc(1) distribution (mandoc.bsd.lv). If there are
> any contradictions between groff_mdoc(7) and mdoc(7), those are
> unintended and i ought to fix them.
>
> So i really believe that the Linux man-pages project ought to
> stop distributing the woefully outdated mdoc.samples(7) manual
> page. If you want to include documentation for the mdoc language,
> i suggest that you either include a copy of the current version
> of the groff_mdoc(7) manual from the groff(1) distribution or
> of the mdoc(7) manual from the mandoc(1) distribution, whichever
> you think harmonizes better with the Linux man-pages project.
> Both are BSD-style licensed, so there should be no licensing
> issues.
>
> I'm not sure whether it is better for you to include or not
> include it. There is probably value in having mdoc(7) documentation
> out of the box with the Linux man-pages project. Then again,
> having groff_mdoc(7) in both the Linux man-pages package and
> in the groff package - or having mdoc(7) in both the Linux
> man-pages project and the mandoc(1) package - might cause
> packaging conflicts for some distributions. I don't rightly
> know how such conflicts are typically handled by Linux
> distributions. Not being able to install the Linux man-pages
> pages project, groff(1) and mandoc(1) all together on the same
> Linux machine would certainly be a bad situation...
>
> By the way, the mdoc(7) manual page distributed by the Linux
> man-pages project also makes very little sense. It is a partial
> repetition of information from groff_mdoc(7)/[mandoc-]mdoc(7),
> but so compressed that it is mostly unintelligible. Besides,
> it is incomplete: e.g. .Lk, .Mt, .Dx, .Ox, .Nx, .Ta, .%U, .Bk,
> .Ek, .Lb, .In, .Ft, .Ms, .Brq, .Bro, .Brc, .Ex are missing -
> it seems outdated by at lest 25 years. Also, some claims are
> outright wrong - for example, you *cannot* use .UR/.UE in an
> mdoc(7) document, and i cannot remember ever having seen an
> implementation of a .UN macro anywhere. Some macros descriptions
> are also wrong, e.g. .Fd is *not* intended for "function
> declarations", and .Vt is *not* "Fortran only". And so on.
>
> 2. I don't recommend keeping the old mdoc.samples(7) and mdoc(7)
> manual pages, but if you think you must do that for some reason,
> then you must at least revert this bogus commit:
I am *not at all* attached to keeping to these pages. Their
presence in the project has always felt a bit anomalous to me.
Back when I took over maintainership in 2004, there were a small
number of pages that used mdoc markup, and so it seemed wise
to keep these pages. Over time, most of those few pages were
converted to 'man' markup, and today the only other page in the
project that still uses mdoc markup is in queue(3). So, there is
just about zero value in having 'mdoc' documentation come with
the "Linux man-pages" box.
Since I seldom use mdoc markup myself, I've had no reason to
monitor pages such as groff_mdoc(7) or the mdoc(7) page
provided my ther 'mandoc' project and compare them with
the pages provided by "Linux man-pages". Now I've had a
closer look. It's sad.
I've removed mdoc(7) and mdoc.samples(7) from "Linux -man-pages".
]]
*roff escape sequences may sometimes look like C escapes, but that
is misleading. *roff is in part a macro language and that means
recursive expansion to arbitrary depths.
You can get away with "\\" in a context where no macro expansion
is taking place, but try to spell a literal backslash this way in
the argument to a macro and you will likely be unhappy with
results.
Try viewing the attached file with "man -l".
"\e" is the preferred and portable way to get a portable "escape
literal" going back to CSTR #54, the original Bell Labs troff
paper.
groff(7) discusses the issue:
\\ reduces to a single backslash; useful to delay its
interpretation as escape character in copy mode. For a
printable backslash, use \e, or even better \[rs], to be
independent from the current escape character.
As of groff 1.22.4, groff_man(7) does as well:
\e Widely used in man pages to represent a backslash output
glyph. It works reliably as long as the .ec request is
not used, which should never happen in man pages, and it
is slightly more portable than the more exact ‘\(rs’
(“reverse solidus”) escape sequence.
People not concerned with portability to extremely old troffs should
probably just use \(rs (or \[rs]), as it means "the backslash
glyph", not "the glyph corresponding to whatever the current escape
character is".
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Wed, 27 Feb 2019 11:23:42 +0000 (12:23 +0100)]
adjtimex.2, futex.2, mremap.2, seccomp.2, getnameinfo.3, random.3, console_codes.4, sysfs.5, sched.7, unicode.7: Use zero‐width space in appropriate locations
Quoting Branden:
*roff systems will interpret the period in the unpatched
page as sentence-ending punctuation and put inter-sentence
spacing after it. (This might not be visible on
nroff/terminal devices, but it is more likely to be on
typesetter/PostScript/PDF output).
groff_man(7) in groff 1.22.4 attempts to throw man page
writers a bone here:
\& Zero‐width space. Append to an input line to prevent
an end‐of‐ sentence punctuation sequence from being
recognized as such, or insert at the beginning of an
input line to prevent a dot or apostrophe from being
interpreted as the beginning of a roff request.
Reported-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is> Reported-by: G. Branden Robinson <g.branden.robinson@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
fanotify_mark.2, fanotify.7: Document FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM
New event masks have been added to the fanotify API. Documentation to
support the use and behaviour of these new masks has been added
accordingly.
Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Tue, 26 Feb 2019 11:13:23 +0000 (12:13 +0100)]
ld.so.8: LD_PRELOAD-ed objects are added to link map in left-to-right order
Remove any doubt, in case the reader might wrongly think that
objects are added in reverse order (which would mean that the
last listed object would be added at the front of the link map).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
You can also see this in the various implementations of
->get_unmapped_area() - if the specified address isn't available,
the kernel basically ignores the hint (apart from the 5level
paging hack).
Clarify how this works a bit.
Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Nikola Forró [Fri, 22 Feb 2019 16:14:14 +0000 (17:14 +0100)]
socket.2: Remove notes concerning AF_ALG and AF_XDP
All address families are now documented in address_families.7,
which is already present in SEE ALSO section. Also, the AF_ALG
note contains dead link to kernel HTML documentation.
Signed-off-by: Nikola Forró <nforro@redhat.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
sigaction.2: Describe obsolete usage of struct sigcontext as signal handler argument
* man2/sigaction.2 (.SS Undocumented): Provide information about
relation between the second argument of sa_handler and
uc_mcontext field of the struct ucontext structure.
Signed-off-by: Eugene Syromyatnikov <evgsyr@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
bert hubert [Sun, 24 Feb 2019 10:18:11 +0000 (11:18 +0100)]
ip.7: IP_RECVTTL error fixed
I need to get the TTL of UDP datagrams from userspace, so I set
the IP_RECVTTL socket option. And as promised by ip.7, I then get
IP_TTL messages from recvfrom. However, unlike what the manpage
promises, the TTL field gets passed as a 32 bit integer.
Michael Kerrisk [Tue, 12 Feb 2019 15:56:13 +0000 (16:56 +0100)]
capabilities.7: Substantially rework "Capabilities and execution of programs by root"
Rework for improved clarity, and also to include missing details
on the case where (1) the binary that is being executed has
capabilities attached and (2) the real user ID of the process is
not 0 (root) and (3) the effective user ID of the process is 0
(root).
Kernel code analysis and some test code (GPLv3 licensed) below.
======
My analysis of security/commoncaps.c capabilities handling
(from Linux 4.20 source):
execve() eventually calls __do_execve_file():
__do_execve_file()
|
+-prepare_bprm_creds(&bprm)
| |
| +-prepare_exec_creds()
| | |
| | +-prepare_creds()
| | |
| | | // Returns copy of existing creds
| | |
| | +-security_prepare_creds()
| | |
| | +-cred_prepare() [via hook]
| | // Seems to do nothing for commoncaps
| |
| // Returns creds provided by prepare_creds()
|
// Places creds returned by prepare_exec_creds() in bprm->creds
|
|
+-prepare_binprm(&bprm) // bprm from prepare_bprm_creds()
|
+-bprm_fill_uid(&bprm)
|
| // Places current credentials into bprm
|
| // Performs set-UID & set-GID transitions if those file bits are set
|
+-security_bprm_set_creds(&bprm)
|
+-bprm_set_creds(&bprm) [via hook]
|
+-cap_bprm_set_creds(&bprm)
|
// effective = false
|
+-get_file_caps(&bprm, &effective, &has_fcap)
| |
| +-get_vfs_caps_from_disk(..., &vcaps)
| |
| | // Fetches file capabilities from disk and places in vcaps
| |
| +-bprm_caps_from_vfs_caps(&vcaps, &bprm, &effective, &has_fcap)
|
| // If file effective bit is set: effective = true
| //
| // If file has capabilities: has_fcap |= true
| //
| // Perform execve transformation:
| // P'(perm) = F(inh) & P(Inh) | F(Perm) & P(bset)
|
+-handle_privileged_root(&bprm, has_fcap, &effective, root_uid)
|
| // If has_fcap && (rUID != root && eUID == root) then
| // return without doing anything
| //
| // If rUID == root || eUID == root then
| // P'(perm) = P(inh) | P(bset)
| //
| // If eUID == root then
| // effective = true
|
// Perform execve() transformation:
//
// P'(Amb) = (privprog) ? 0 : P(Amb)
// P'(Perm) |= P'(Amb)
// P'(Eff) = effective ? P'(Perm) : P'(Amb)
Summary
1. Perform set-UID/set-GID transformations
2. P'(Amb) = (privprog) ? 0 : P(Amb)
3. If [process has nonzero UIDs] OR
([file has caps] && [rUID != root && eUID == root]), then