The marking matches glibc marking.
The marking of functions in glibc is:
- clearenv: MT-Unsafe const:env
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.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>
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>
After research, We think fexecve() is thread-safe. But, there
is not marking of fexecve() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
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>
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>
After research, We think profil() is not thread-safe. But,
there is not marking of profil() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
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>
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>
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>
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>
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>
After research, We think sem_close() is thread-safe. But, there
is not marking of sem_close() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- rpmatch: MT-Safe locale
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think malloc_trim() is thread-safe. But, there
is not marking of malloc_trim() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think malloc_get_state() and malloc_set_state() 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>
After research, We think getrpcport() is thread-safe. But, there
is not marking of getrpcport() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think getnameinfo() is thread-safe. But, there
is not marking of getnameinfo() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think getaddrinfo(), freeaddrinfo() and
gai_strerror() 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>
Michael Kerrisk