Permission to access /proc/PID/timerslack_ns is governed by
a PTRACE_MODE_ATTACH_FSCREDS ptrace access mode check.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Permission to access /proc/PID/{auxv,environ,wchan} is governed by
a PTRACE_MODE_READ_FSCREDS ptrace access mode check.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Permission to access /proc/PID/{maps,pagemap} is governed by a
PTRACE_MODE_READ_FSCREDS ptrace access mode check.
Permission to access /proc/PID/mem is governed by a
PTRACE_MODE_ATTACH_FSCREDS ptrace access mode check.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since we now know that glibc does not support all the keywords
mentioned in ISO/IEC TR 14652 [1] and in general glibc aims to
be conforming to POSIX first and foremost, I think it's best
just to drop the reference to ISO/IEC TR 14652 from the man page.
1) http://www.open-std.org/jtc1/SC22/WG20/docs/n972-14652ft.pdf
After this I think the locale related man pages are finally as
complete as they need to be.
Cross-checked the current locale.5 page against glibc locales and
fixed the following issues:
- mention define/ifdef/else/endif
- mention reorder-sections-{after,end}
- mention script
- section/section-symbol are not used, only mentioned in the ISO TR
- Fix int_currency_symbol -> int_curr_symbol typo
- few formatting fixes
All the glibc locale/repertoiremap files use the format described
in the patch. The fix is trivial (and adds an example just in
case), I presume these were copypasted from charmaps.5 page, all
the glibc charmaps use slightly different format for keywords
(I'll send a separate patch to address charmaps.5 next).
There was partial duplication, and some extra information
in namespaces(7). Move everything to proc(5).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Here's the first attempt to (almost) complete the locale.5 manual
page by documenting all (but perhaps one) of the missing
LC_COLLATE keywords.
I think the LC_COLLATE section is still not enough to be used as
the only source when writing collation rules from scratch but
perhaps that's not even needed, it could be also thought that
the section 5 pages merely describe the format used in the files.
Naturally more information could be added later on top of this
patch.
Few notes:
- AFAICS coll_weight_max is not used anywhere in glibc
- I'm not aware of any C library implementation on Linux (for
which this manual page would be relevant) which would
implement the POSIX options not supported by glibc
- the glibc specific script keyword could still be documented
Sources:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.htmlhttp://www.open-std.org/jtc1/SC22/WG20/docs/n972-14652ft.pdf
PS. A couple of unrelated comment clean-ups slipped in as well,
sorry about those.
Document DirectMap4k, DirectMap4M, DirectMap2M, DirectMap1G
See https://bugzilla.kernel.org/show_bug.cgi?id=106281
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Quoting Mike:
gabi says:
https://refspecs.linuxbase.org/elf/gabi4+/ch4.symtab.html
A symbol defined in the current component is protected if it is
visible in other components but not preemptable, meaning that
any reference to such a symbol from within the defining component
must be resolved to the definition in that component, even if
there is a definition in another component that would preempt by
the default rules. A symbol with STB_LOCAL binding may not have
STV_PROTECTED visibility. If a symbol definition with
STV_PROTECTED visibility from a shared object is taken as
resolving a reference from an executable or another shared object,
the SHN_UNDEF symbol table entry created has STV_DEFAULT
visibility.
solaris/oracle says:
https://docs.oracle.com/cd/E26502_01/html/E26507/chapter6-79797.html
A symbol that is defined in the current component is protected
if the symbol is visible in other components, but cannot be
preempted. Any reference to such a symbol from within the defining
component must be resolved to the definition in that component.
This resolution must occur, even if a symbol definition exists in
another component that would interpose by the default rules.
A symbol with STB_LOCAL binding will not have STV_PROTECTED
visibility.
but i think this ibm article is probably the most understandable:
https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/
The symbol is visible outside the current executable or shared
object, but it may not be overridden. In other words, if a
protected symbol in a shared library is referenced by an other
code in the shared library, the other code will always reference
the symbol in the shared library, even if the executable defines
a symbol with the same name.
Reported-by: Gabriel Corona <gabriel.corona@enst-bretagne.fr>
Reported-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Note also the pre-3.1 bug in the display of this info.
Reported-by: Patrick Donnelly <batrick@batbytes.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The ELF header section's e_shstrndx contained a duplicate
description of the SHN_* special section header indices.
Remove them.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From the current description of NSS compatibility mode it seems
that /etc/passwd is the only file where special entries are
permitted. But "compat" service can also be specified for group
and shadow databases, so this needs to be changed.
The list of special entries is for passwd database only, group
and shadow databases are not mentioned. Because group database
does not support netgroup special entries and it deals with
groups, not users, it is better to make a separate list
of entries for it.
It is true that the default source for the compat pseudo-databases
is "nis", but it can be overridden by any NSS service, not just
"nisplus". Even "compat" itself can be specified as the source for
the pseudo-databases, but doing that of course leads to infinite
recursion, so it makes sense to disallow that.
The information was obtained from glibc source code, namely from
the following files:
nis/nss_compat/compat-pwd.c
nis/nss_compat/compat-grp.c
nis/nss_compat/compat-spwd.c
Signed-off-by: Nikola Forró <nforro@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Kernel 4.4 added two new core dump filtering flags,
MMF_DUMP_DAX_PRIVATE and MMF_DUMP_DAX_SHARED.
These flags allow us to explicitly filter DAX mappings.
This is desirable because DAX mappings, like hugetlb
mappings, have the potential to be very large.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This is not mentioned anywhere. Users can assume that the file
being read is something like /etc/$DATABASE, but that's not
always the case. It's better to explicitly specify which
file is read for each respective database. The list of
files was acquired from glibc source code.
Signed-off-by: Nikola Forró <nforro@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add detail information for threads-max.
The checks for minimum and maximum values exist since kernel 4.1.
https://lkml.org/lkml/2015/3/15/96
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
To some degree, this is true of many pages. And anyway, this
page is much better after recent work by Marko.
Reported-by: Marko Myllynen <myllynen@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Based on text in Documentation/sysctl/kernel.txt.
Cowritten-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In some recent work with a Red Hat customer I had the opportunity
to discuss the fine nuances of the ruserok() function and related
API which are used to implement rlogin and rsh.
It came to my attention after working with QE on some automated
internal testing that there were no good examples in the hosts.equiv
manual page showing how the format was supposed to work for this
file and for ~/.rhosts, worse the "format" line showed that there
should be spaces between arguments when that would clearly lead
to incorrect behaviour. In addition some things that the format
allows you to write are just wrong like "-host -user" which makes
no sense since the host is already rejected, and should be written
as "host -user" instead. I added notes in the example to make it
clear that "-host -user" is invalid.
I fixed three things:
(a) The format line.
- Either +, or [-]hostname, or +@netgrp or -@netgrp.
- Either +, or [-]username, or +@netgrp or -@netgrp.
- You must specify something in the hostname portion so remove
optional brackets.
(b) Clarify language around credentials
- If the host is not trusted you must provide credentials to
the login system and that could be anything really and it
depends on your configuration e.g. PAM or whatever IdM you have.
(c) Provide real-world examples
- Provide several real world examples and some corner case
examples for how you would write something. Hopefully others
can add examples as they see fit.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Sort the options so that those defined in POSIX are listed first,
then followed by those defined in ISO/IEC TR 14652 in the order
of common convention in many widely used glibc locales.
Actual descriptions are unchanged.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The timezone of LC_TIME is not in POSIX, only 6 (out of ~300)
glibc locales define it, the glibc code comment below from
glibc.git/programs/ld-time.c seems to suggest it's not a good
idea, and there's been a proposal in upstream [1] to remove the
existing timezone definitions from glibc locales so I think
it's actually better to leave this one undocumented:
/* XXX We don't perform any tests on the timezone value since this is
simply useless, stupid $&$!@... */
1) https://sourceware.org/ml/libc-alpha/2015-06/msg00098.html
Move the remaining LC_COLLATE FIXMEs together while at it.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The relationship between the locale time format syntax
and strftime() cannot be considered as obvious.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It's probably a good idea to refer to locale(7) so that a reader
can check what a category is about before describing them in
detail.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A long time ago in glibc, repertoire maps were used (but they
were removed already in 2000), those mapping files were named
as mnemonics, so "mnemonic" is a term that would almost
certainly come up if somebody studies glibc side (perhaps even
the related standards like ISO 9945 [which I don't have access
to]) so I thought it's worth to mention to term in the man page
to make sure we're talking about the same thing, otherwise
someone might wonder is that something different or not.
IOW, symbolic names and mnemonics are often used interchangeably,
let's mention the other often used term in the page, too.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Both plain numbers and Unicode code points are used in glibc locales but checking the code reveals that country_isbn is handled like the rest of its category expect for country_num which was clarified earlier.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>