Received: (qmail 79775 invoked by uid 501); 19 Dec 2000 20:48:44 -0000 Message-Id: <20001219204844.79774.qmail@locus.apache.org> Date: 19 Dec 2000 20:48:44 -0000 From: James Feeney Reply-To: james@nurealm.net To: submit@bugz.apache.org Subject: Desire selective Group write permissions for CGI programs which require group development. X-Send-Pr-Version: 3.110 >Number: 6996 >Category: suexec >Synopsis: Desire selective Group write permissions for CGI programs which require group development. >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: closed >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: apache >Arrival-Date: Tue Dec 19 12:50:00 PST 2000 >Closed-Date: Tue Dec 19 13:49:37 PST 2000 >Last-Modified: Tue Dec 19 13:49:37 PST 2000 >Originator: james@nurealm.net >Release: 1.3.14 >Organization: >Environment: RedHat Linux 2.2.16-3, with Apache 1.3.3 >Description: "Apache suEXEC Support" documentation has, in part, the constraints: 14.Is the directory NOT writable by anyone else? 16.Is the target program NOT writable by anyone else? which can produce the suexec log errors "directory is writable by others:" and "file is writable by others:" if violated. These constraints disallow any kind of group CGI program development, in particular, within the configured virtual host ScriptAlias directory for the cgi-bin directory, unless by forcing all developers to log in as the same user, which is not a good solution. Simply disabling these constraints globally may also not be the most desirable solution. Can we have some configuration option which will allow selective CGI program execution for programs with group write permission on the file and cgi-bin directory? With properly configured groups, disallowing execution of files with group write permissions may be convenient at times but is no more secure than execution of files with user write permissions, and suexec should not presume incompetence of the part of the administrator. Arguing about this issue with customers is also not a useful solution. >How-To-Repeat: standard suexec configuration >Fix: How about a "GroupExec yes" directive? Or, maybe better, a "groupexec" keyword for the Group directive? As a quick hack, group write permission checking can be disabled in suexec, but the point is to avoid that. >Release-Note: >Audit-Trail: State-Changed-From-To: open-closed State-Changed-By: slive State-Changed-When: Tue Dec 19 13:49:34 PST 2000 State-Changed-Why: I understand your desire for more flexibility here. However, you need to understand that suexec is specifically designed to be extremely simple and very inflexible. Any other design would multiply possible sources of security problems in an already dangerous type of program. You may like to look into other ways of running suid CGI scripts (eg. cgiwrap). Alternatively, if you understand all the consequences, you can always modify the source code to do what you want. Adding a configuration directive to do this would lead people who don't understand the consequences to be more likely to hurt themselves. In addition, it is fundementally very difficult or impossible to safely pass configuration information from Apache to suexec. Thanks for using Apache. Release-Changed-From-To: any-1.3.14 Release-Changed-By: slive Release-Changed-When: Tue Dec 19 13:49:34 PST 2000 >Unformatted: [In order for any reply to be added to the PR database, you need] [to include in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as "general/1098:" or ] ["Re: general/1098:"). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] ["apbugs" address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]