httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 7862] - suexec never log a group name.
Date Sat, 13 Nov 2004 09:00:31 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=7862>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=7862

suexec never log a group name.





------- Additional Comments From warp-9.9@usa.net  2004-11-13 09:00 -------
To be more precise (referring to the support/suexec.c found in the current
version of httpd-2.0.52), the suexec actual_gname is incorrectly reported as a
numeric group id and not as an alphanumeric group name.

I will attach my patch and ask people to try it out.  However I'd like to list
the changes here to be clear in psuedo code.

1.0) If the string does not contain only characters that represent
     numbers 0-9 (numeric group id),
     then we assume it is an alphanumeric group name,
1.1) and we try to look for the group by name.
1.2) If the alphanumeric group name can not be found, we log an error and exit.
2.0) Otherwise we assume that the string contains only characters
     that represent numbers 0-9 (numeric group id),
2.1) we convert the string to an integer,
2.2) and we try to look for the group by number.
2.3) If the numeric group id can not be found, we log an error and exit.
3.0) If we made it this far, we assume that we have found a valid group.
3.1) We assign the actual numeric group id to a placeholder variable,
3.2) and we assign the actual group name to a placeholder variable.

Note: Contrary to previous concern, there is only one call to access the group
file.  The string can either be all characters which represent numbers, or it
can have one ormore non-numeric characters.  It can not be both.  Either
getgrnam or getgrgid will be called, but not both.  Furthermore, the redundant
assignments are consolidated.  Once the group data is available, the assignments
are exactly the same, such that they can logically follow the outer if/else
construct because they will be performed in either case, so long as either of
the inner ifs do not exit.  If they exit, we don't have to worry beyond that point.

Patched code:

    /*
     * Error out if the target group name is invalid.
     */
    if (strspn(target_gname, "1234567890") != strlen(target_gname)) {
        if ((gr = getgrnam(target_gname)) == NULL) {
            log_err("invalid target group name: (%s)\n", target_gname);
            exit(106);
        }
    }
    else {
        if ((gr = getgrgid(atoi(target_gname))) == NULL) {
            log_err("invalid target group id: (%s)\n", target_gname);
            exit(106);
        }
    }

    gid = gr->gr_gid;
    actual_gname = strdup(gr->gr_name);

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message