Re: Documenting execve() and EAGAIN

[NeilBrown]

On Wed, 21 May 2014 20:12:32 +0200 "Michael Kerrisk (man-pages)"
<mtk.manpages@xxxxxxxxx> wrote:

> 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.

I don't know how detailed/precise you want to be, but this failure was from
2.6.0 to 3.0.
Prior to 2.6, the limit was not imposed on processes that changed their uid.

http://git.kernel.org/cgit/linux/kernel/git/history/history.git/commit/?id=909cc4ae86f3380152a18e2a3c44523893ee11c4

$ git describe --contains 909cc4ae86f3380152a18e2a3c44523893ee11c4
v2.6.0-test2~85^2~5^2~15

Otherwise the description fits my understanding.

NeilBrown

> 
>        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.
>

Attachment: signature.asc
Description: PGP signature