You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2022/09/28 10:01:35 UTC

[Bug 66280] New: ap_uname2id() / ap_gname2id() disregard errno (esp. EINTR) from getpwnam() / getgrnam()

https://bz.apache.org/bugzilla/show_bug.cgi?id=66280

            Bug ID: 66280
           Summary: ap_uname2id() / ap_gname2id() disregard errno (esp.
                    EINTR) from getpwnam() / getgrnam()
           Product: Apache httpd-2
           Version: 2.5-HEAD
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core
          Assignee: bugs@httpd.apache.org
          Reporter: overripper@gmail.com
  Target Milestone: ---

Apache uses the aforementioned calls to resolve configured users/groups during
startup, i.e. SuexecUserGroup directives in mod_suexec.

The respective code (server/mpm_common.c) checks the return value from
getpwnam()/getgrnam() and exits the process with an error message if it's NULL.

The assumption here is that the username/group does not exist if the functions
return NULL. But according to the standard library documentation, NULL could
also be returned if an error occurs. Only errno could be used to determine
whether we have a bad user/group indeed or an error or signal has interrupted
the call.


       0 or ENOENT or ESRCH or EBADF or EPERM or ...
              The given name or uid was not found.

       EINTR  A signal was caught; see signal(7).

       EIO    I/O error.

An issue I encounter semi-regularly is having some signal interrupt Apache
during restart while being inside one of these calls and the webserver dying
with "AH00544: httpd: bad group name groupname". This is similar in effect to a
crash, since it's dying for no real reason.

My proposal here is to use errno and handle EINTR with a retry so that the
server is no longer dying when it could have continued without issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org