Michael Kerrisk [Tue, 30 Jun 2015 11:39:39 +0000 (13:39 +0200)]
prctl.2, seccomp.2: Clarify that SECCOMP_SET_MODE_STRICT disallows exit_group(2)
These days, glibc implements _exit() as a wrapper around
exit_group(2). (When seccomp was originally introduced, this was
not the case.) Give the reader a clue that, despite what glibc is
doing, what SECCOMP_SET_MODE_STRICT permits is the true _exit(2)
system call, and not exit_group(2).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Carlos O'Donell [Sun, 24 May 2015 04:58:25 +0000 (00:58 -0400)]
hosts.equiv.5: Fix format, clarify IdM needs, and provide examples.
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>
Jann Horn [Sun, 14 Jun 2015 11:25:04 +0000 (13:25 +0200)]
chroot.2: chroot() is not intended for security; document attack
It is unfortunate that this discourages this use of chroot(2)
without pointing out alternative solutions - for example,
OpenSSH and vsftpd both still rely on chroot(2) for security.
Bind mounts should theoretically be usable as a replacement, but
currently, they have a similar problem (CVE-2015-2925) that hasn't
been fixed in ~6 months, so I'd rather not add it to the manpage
as a solution before a fix lands.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Zeng Linggang [Thu, 11 Jun 2015 02:04:30 +0000 (10:04 +0800)]
setaliasent.3: ATTRIBUTES: Note functions that are/aren't thread-safe
After research, We think
* setaliasent(),
* endaliasent(),
* getaliasent_r(),
* getaliasbyname_r(),
are thread-safe. And
* getaliasent(),
* getaliasbyname(),
are not thread-safe. But, there are not
markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Zeng Linggang [Thu, 11 Jun 2015 02:04:29 +0000 (10:04 +0800)]
resolver.3: ATTRIBUTES: Note functions that are thread-safe
After research, We think
* res_ninit(),
* res_nquery(),
* res_nsearch(),
* res_nquerydomain(),
* res_nmkquery(),
* res_nsend(),
* dn_comp(),
* dn_expand()
are thread-safe. But, there are not
markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Zeng Linggang [Thu, 11 Jun 2015 02:04:28 +0000 (10:04 +0800)]
rcmd.3: ATTRIBUTES: Note functions that are/aren't thread-safe
After research, We think
* rresvport(),
* iruserok(),
* ruserok(),
* rresvport_af(),
* iruserok_af(),
* ruserok_af(),
are thread-safe. And
* rcmd(),
* rcmd_af(),
are not thread-safe. But, there are not
markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Zeng Linggang [Thu, 11 Jun 2015 02:04:26 +0000 (10:04 +0800)]
getservent_r.3: ATTRIBUTES: Note functions that are thread-safe
After research, We think
* getservent_r(),
* getservbyname_r(),
* getservbyport_r(),
are thread-safe. But, there are not
markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Zeng Linggang [Thu, 11 Jun 2015 02:04:25 +0000 (10:04 +0800)]
getrpcent_r.3: ATTRIBUTES: Note functions that are thread-safe
After research, We think
* getrpcent_r(),
* getrpcbyname_r(),
* getrpcbynumber_r(),
are thread-safe. But, there are not
markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Zeng Linggang [Thu, 11 Jun 2015 02:04:24 +0000 (10:04 +0800)]
getrpcent.3: ATTRIBUTES: Note functions that are/aren't thread-safe
After research, We think
* setrpcent(),
* endrpcent(),
are thread-safe. And
* getrpcent(),
* getrpcbyname(),
* getrpcbynumber(),
are not thread-safe. But, there are not
markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Zeng Linggang [Thu, 11 Jun 2015 02:04:23 +0000 (10:04 +0800)]
getprotoent_r.3: ATTRIBUTES: Note functions that are thread-safe
After research, We think
* getprotoent_r(),
* getprotobyname_r(),
* getprotobynumber_r(),
are thread-safe. But, there are not
markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Zeng Linggang [Thu, 11 Jun 2015 02:04:22 +0000 (10:04 +0800)]
getaddrinfo_a.3: ATTRIBUTES: Note functions that are thread-safe
After research, We think
* getaddrinfo_a(),
* gai_suspend(),
* gai_error(),
* gai_cancel(),
are thread-safe. But, there are not
markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Zeng Linggang [Thu, 11 Jun 2015 02:04:21 +0000 (10:04 +0800)]
fts.3: ATTRIBUTES: Note functions that are/aren't thread-safe
After research, We think
* fts_open(),
* fts_set(),
* fts_close(),
are thread-safe. And
* fts_read(),
* fts_children(),
are not thread-safe. But, there are not
markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Zeng Linggang [Wed, 27 May 2015 10:12:59 +0000 (18:12 +0800)]
pthread_attr_setaffinity_np.3: ATTRIBUTES: Note functions that are thread-safe
After research, We think pthread_attr_setaffinity_np() and
pthread_attr_getaffinity_np() are thread-safe. But, there are not
markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Zeng Linggang [Wed, 27 May 2015 10:12:58 +0000 (18:12 +0800)]
key_setsecret.3: ATTRIBUTES: Note functions that are thread-safe
After research, We think key_decryptsession(), key_setsecret(),
key_encryptsession(), key_gendes() and key_secretkey_is_set() are
thread-safe. But, there are not markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In the "RETURN VALUE" section the word item is in italics
as if it were one of the function parameters. But the word
"item" occurs here for the first time, earlier the text
uses "element". [Patch improves this.]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Marko Myllynen [Tue, 9 Jun 2015 14:19:53 +0000 (17:19 +0300)]
locale.5: Sort according to the standard
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.
Marko Myllynen [Tue, 9 Jun 2015 14:19:14 +0000 (17:19 +0300)]
locale.5: Remove the FIXME for timezone
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 $&$!@... */
projects / thirdparty / man-pages.git / log
