suexec never log a group name. I think the following patch works fine: Index: support/suexec.c =================================================================== RCS file: /Apache/CVS/httpd-2.0-cvs/support/suexec.c,v retrieving revision 1.19 diff -u -r1.19 suexec.c --- support/suexec.c 13 Mar 2002 20:48:06 -0000 1.19 +++ support/suexec.c 9 Apr 2002 11:16:02 -0000 @@ -399,7 +399,11 @@ } else { gid = atoi(target_gname); - actual_gname = strdup(target_gname); + if ((gr = getgrgid(gid)) == NULL) { + log_err("invalid target group name: (%s)\n", target_gname); + exit(106); + } + actual_gname = strdup(gr->gr_name); } #ifdef _OSD_POSIX
A few comments... The change with this patch is that 1) if group name is specified as a number, the patched code now does a lookup to find the name so that log messages show the name 2) if the group name is specified as a number and it is invalid, the error will be caught a little sooner The cost of this patch is an extra group database lookup. It could be considered a feature that suexec won't read /etc/groups if the group is specified numerically.
Still the same on 2.0.48: [2003-11-07 17:39:33]: uid: (1234/user) gid: (1234/1234) cmd: some.cgi Any result of discussions now whether or not group name should be shown? If not, why then log the gid twice...disabling of the second one will save from 2 to 6 chars per log line ;-) like. [2003-11-07 17:39:33]: uid: (1234/user) gid: (1234) cmd: some.cgi BTW: on most systems, ncsd is running by default, so group name lookup should not cost so much extra time.
I'm going through the bug db to make sure patches are findable. Please see http://httpd.apache.org/dev/patches.html
*** Bug 28690 has been marked as a duplicate of this bug. ***
*** Bug 32220 has been marked as a duplicate of this bug. ***
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);
Created attachment 13429 [details] Patch addresses bug: suexec actual_gname always numeric
Sorry for the multiple posts. I just noticed that this bug is listed under the component "mod_suexec" when I think it is actually a "support" component. Can someone else more familiar please verify and correct? I modified a single file, httpd-2.0.52/support/suexec.c. I did not touch httpd-2.0.52/modules/generators/mod_suexec.*, and these modules were not rebuilt after my changes. Therefore I really think it is a "support" component. This would presumably ensure the right people are aware of the bug. :-) I look forward to hearing about tests performed with this patch. I have tried group names with alpha-only and mixed alpha-numeric, but not with all numeric characters. My Linux distribution's adduser script does not like usernames with all numeric characterrs. If someone can explain how to make (or even why one would want to) a user name with only digits 0-9, then I can manually make the home directory, and edit the users and group files, and updated my shadowed passwords.
Patch applied to trunk (r655711). Thanks!