From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Vasiliy Kulikov <segoon@openwall.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: mtk.manpages@gmail.com,
"linux-man@vger.kernel.org" <linux-man@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Documenting execve() and EAGAIN
Date: Wed, 21 May 2014 20:12:32 +0200 [thread overview]
Message-ID: <537CEC90.7060000@gmail.com> (raw)
Vasily (and Motohiro),
Sometime ago, Motohiro raised a documentation bug
( https://bugzilla.kernel.org/show_bug.cgi?id=42704 ) which
relates to your commit 72fa59970f8698023045ab0713d66f3f4f96945c
("move RLIMIT_NPROC check from set_user() to do_execve_common()")
I have attempted to document this, and I would like to ask you
(and Motohiro) if you would review the text proposed below for
the exceve(2) man page.
Thank you,
Michael
ERRORS
EAGAIN (since Linux 3.1)
Having changed its real UID using one of the set*uid()
calls, the caller was—and is now still—above its
RLIMIT_NPROC resource limit (see setrlimit(2)). For a
more detailed explanation of this error, see NOTES.
NOTES
execve() and EAGAIN
A more detailed explanation of the EAGAIN error that can occur
(since Linux 3.1) when calling execve() is as follows.
The EAGAIN error can occur when a preceding call to setuid(2),
setreuid(2), or setresuid(2) caused the real user ID of the
process to change, and that change caused the process to
exceed its RLIMIT_NPROC resource limit (i.e., the number of
processes belonging to the new real UID exceeds the resource
limit). In Linux 3.0 and earlier, this caused the set*uid()
call to fail.
Since Linux 3.1, the scenario just described no longer causes
the set*uid() call to fail, because it too often led to secu‐
rity holes because buggy applications didn't check the return
status and assumed that—if the caller had root privileges—the
call would always succeed. Instead, the set*uid() calls now
successfully change real UID, but the kernel sets an internal
flag, named PF_NPROC_EXCEEDED, to note that the RLIMIT_NPROC
resource limit has been exceeded. If the resource limit is
still exceeded at the time of a subsequent execve() call, that
call fails with the error EAGAIN. This kernel logic ensures
that the RLIMIT_NPROC resource limit is still enforced for the
common privileged daemon workflow—namely, fork(2)+ set*uid()+
execve(2).
If the resource limit was not still exceeded at the time of
the execve() call (because other processes belonging to this
real UID terminated between the set*uid() call and the
execve() call), then the execve() call succeeds and the kernel
clears the PF_NPROC_EXCEEDED process flag. The flag is also
cleared if a subsequent call to fork(2) by this process suc‐
ceeds.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
next reply other threads:[~2014-05-21 18:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-21 18:12 Michael Kerrisk (man-pages) [this message]
[not found] ` <537CEC90.7060000-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-22 1:41 ` Documenting execve() and EAGAIN NeilBrown
[not found] ` <20140522114102.66129305-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2014-05-22 13:28 ` Michael Kerrisk (man-pages)
2014-05-26 18:11 ` Vasiliy Kulikov
2014-05-27 5:51 ` Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=537CEC90.7060000@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=segoon@openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).