At the kernel level, credentials (UIDs and GIDs) are a per-thread
attribute. NPTL uses a signal-based mechanism to ensure that
when one thread changes its credentials, all other threads change
credentials to the same values. By this means, the NPTL
implementation conforms to the POSIX requirement that the threads
in a process share credentials.
Reported-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At the kernel level, credentials (UIDs and GIDs) are a per-thread
attribute. NPTL uses a signal-based mechanism to ensure that
when one thread changes its credentials, all other threads change
credentials to the same values. By this means, the NPTL
implementation conforms to the POSIX requirement that the threads
in a process share credentials.
Reported-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At the kernel level, credentials (UIDs and GIDs) are a per-thread
attribute. NPTL uses a signal-based mechanism to ensure that
when one thread changes its credentials, all other threads change
credentials to the same values. By this means, the NPTL
implementation conforms to the POSIX requirement that the threads
in a process share credentials.
Reported-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At the kernel level, credentials (UIDs and GIDs) are a per-thread
attribute. NPTL uses a signal-based mechanism to ensure that
when one thread changes its credentials, all other threads change
credentials to the same values. By this means, the NPTL
implementation conforms to the POSIX requirement that the threads
in a process share credentials.
Reported-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At the kernel level, credentials (UIDs and GIDs) are a per-thread
attribute. NPTL uses a signal-based mechanism to ensure that
when one thread changes its credentials, all other threads change
credentials to the same values. By this means, the NPTL
implementation conforms to the POSIX requirement that the threads
in a process share credentials.
Reported-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This was fixed in glibc 2.1.1, which is a long while ago.
And in any case, there is nothing special about this case;
it's just one of those times when glibc lags.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing text makes no sense. The check is based
purely on a capability check. (Kernel function
net/packet/af_packet.c::packet_create()
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Actually a dummy commit to mark the fact that I mashed commit
e8db1b97eb to have the wrong
author. Come release time, I'll at least fix the Changelog
to note that the author was Scot Doyle.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It's important that the reader receive contemporary information.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
While a lot of the changes are issues of presentation,
there are also issues of grammar and punctuation.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Per IEEE-754 rounding rules.
The round(3) page describes the behavior of rint and nearbyint
in the halfway cases by saying:
These functions round x to the nearest integer, but round
halfway cases away from zero [...], instead of to the
nearest even integer like rint(3)
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
On Wed, Mar 11, 2015 at 10:43:50PM +0100, Mikael Pettersson wrote:
> Jann Horn writes:
> > Or should I throw this patch away and write a patch
> > for the prctl() manpage instead that documents that
> > being able to call sigreturn() implies being able to
> > effectively call sigprocmask(), at least on some
> > architectures like X86?
>
> Well, that is the semantics of sigreturn(). It is essentially
> setcontext() [which includes the actions of sigprocmask()], but
> with restrictions on parameter placement (at least on x86).
>
> You could introduce some setting to restrict that aspect for
> seccomp processes, but you can't change this for normal processes
> without breaking things.
Then I think it's probably better and easier to just document the
existing behavior? If a new setting would have to be introduced
and developers would need to be aware of that, it's probably
easier to just tell everyone to use SIGKILL.
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Mikael Pettersson <mikpelinux@gmail.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Fix a warning of groff: line 527: warning [p 6, 2.3i]: cannot adjust line
Signed-off-by: Stéphane Aulery <saulery@free.fr>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Fix a warning of groff: line 192: warning [p 2, 4.7i]: cannot adjust line
Signed-off-by: Stéphane Aulery <saulery@free.fr>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Looking over the man page for 'tcp' I came across a reference to
tuning the 'TCP_SYNQ_HSIZE' parameter when increasing
'tcp_max_syn_backlog' above 1024. However, this static sizing was
removed back in Linux 2.6.20 in favor of dynamic scaling - as
part of commit 72a3effaf633bcae9034b7e176bdbd78d64a71db.
I have included a patch below with reference to this commit, and
that the process detailed is not required on >= Linux 2.6.20.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk