Re: suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures
The following reply was made to PR suexec/1769; it has been noted by GNATS. From: Gary Shea [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures Date: Wed, 11 Nov 1998 02:01:46 -0700 (MST) Hi folks -- Some time ago I created a set of patches for 1.3b3 which allow suexec to work in a more flexible manner; those patches are getting a bit dated, and I've got a new set (for 1.3.3) pretty much ready to go. I've attempted to follow the spirit of the changes that have been made since 1.3b3. The patches are still intolerant of variation in the formatting of the suexec.conf file, but otherwise are fairly solid (I think!). Since the configure stuff has become very slick and useful, I'm wondering if I can get a copy of the configure.in file so I can add a few --suexec-* options to the patches so some additional configuration can be automated. For instance, I need to set up where the suexec.conf file is found (and what it's called, for that matter...). Once I have the configure changes done I'd like to re-release the patches. I have lost track of who handled that, so I'd appreciate it if you could let me know... I made (sparing) use of the request rec's 'notes' field, and for the first time used the space management stuff implemented in alloc.c ... wow, is that stuff nice. Beautiful work. Whoever did it was thinking. Gary - Gary Shea [EMAIL PROTECTED] Salt Lake City http://www.xmission.com/~shea
Re: suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures
[In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] Synopsis: suexec too limited -- need per-directory control, more permissive directory structures State-Changed-From-To: open-closed State-Changed-By: brian State-Changed-When: Mon May 4 21:22:20 PDT 1998 State-Changed-Why: submitted patch added to the contrib/patches/1.3 distribution directory.
Re: suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures
The following reply was made to PR suexec/1769; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures Date: Mon, 27 Apr 1998 11:32:21 -0700 (PDT) -- Forwarded message -- Date: Mon, 27 Apr 1998 12:12:49 -0400 To: [EMAIL PROTECTED] From: Jonathan Roy [EMAIL PROTECTED] I'd just like to second PR #1769's request for more flexability in suexec. The only thing I wanted to use it for was to set cgis in the adverts/ directory to their own user/group, one just for the ad engine, so other users couldn't screw it up with their own cgis (which would have the same permissions). Maybe 1.4 or 2.0 will have that I guess. Some sort of Directory based User/Group model. Then each seperate application could have it's own user/group permissions... -Jonathan -- Jonathan Roy - [EMAIL PROTECTED] - Idle Communications, Inc.
Re: suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures
The following reply was made to PR suexec/1769; it has been noted by GNATS. From: Gary Shea [EMAIL PROTECTED] To: Dean Gaudet [EMAIL PROTECTED] Cc: Gary Shea [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures Date: Wed, 11 Feb 1998 00:36:03 -0700 (MST) On Wed, 4 Feb 1998, Dean Gaudet wrote: At any rate. If you've got the patches for 1.2 already, you could send them along so that we at least see what you mean... I'd be surprised if this isn't possible. Dean Dean -- Did you receive the patches I sent you for mod_cgi.c and suexec.c and util_call.c? I had goofed up the mail and sent the patches to apbugs myself the first time, and just to you the second time. Gary - Gary Shea [EMAIL PROTECTED] Salt Lake City http://www.xmission.com/~shea
Re: suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures
The following reply was made to PR suexec/1769; it has been noted by GNATS.
From: Gary Shea [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: suexec/1769: suexec too limited -- need per-directory control,
more permissive directory structures
Date: Fri, 6 Feb 1998 13:30:23 -0700 (MST)
As promised, patches. These patches were inspired by, and to some
extent stolen from, Philippe Vanhaesendonck's ([EMAIL PROTECTED])
mod_cgi_sugid patches. Philippe's code/concept functioned entirely
in mod_cgi and is no longer workable in 1.3b3 (I've not looked at
1.2.* since 1.2b10), but is the source of the UserID and GroupID
directive support code.
I have hacked mod_cgi to directly request a uid/gid from call_exec()
if there is an applicable UserID and/or GroupID. call_exec() respects
directly requested uid/gid's absolutely, but if none is specified, it'll
still detect ~user uri's and pass the appropriate uid/gid to suexec.
Thus it's identical from the point of view of mod_include, but can
still give mod_cgi what it wants/expects..
suexec is heavily hacked to suck up a configuration file more or less
akin to standard apache config files, but I didn't attempt to use
apache code -- it's my proof of concept I guess, easier to code it
for testing than to work out integrating the apache code. As a result
the config files are quite picky about case, etc.. Also there
are some holes still insofar as what happens if some of the
directives are not specified. I won't bother to fix those holes
unless someone else wants to use this code.
The configuration file takes three directives at present;
everything else remains compiled in. Here's an example.
UserDirSuffix: public_html/cgi-bin
UserDirectories: on
Directory: /users/src/a13b3/htd3/cgi-bin
Directory: /users/src/a13b3/htd2/cgi-bin
Directory: /users/src/a13b3/htd5/cgi-bin
I have not yet converted suexec to a simple forking server sitting
on a Unix socket, but if ther are adverse effects from startup time,
I will. Since most of what I run are large Perl codes that take close
to a second to compile, that's unlikely!
Here's a clip of a configuration file which uses the UserID and GroupID
directives:
ScriptAlias /htd2/cgi-bin /users/src/a13b3/htd2/cgi-bin
Location /htd2/cgi-bin
Limit GET POST
UserId shea
GroupId users
/Limit
/Location
And HEEERE'S the PATCHES!
diff -c --exclude=*.[oa] --recursive apache_1.3b3/src/Configuration
a13b3/src/Configuration
*** apache_1.3b3/src/Configuration Wed Nov 19 17:49:57 1997
--- a13b3/src/ConfigurationWed Feb 4 22:48:13 1998
***
*** 41,47
# Settings here have priority; If not set, Configure will attempt to guess
# the C compiler, looking for gcc first, then cc.
#
! EXTRA_CFLAGS=
EXTRA_LDFLAGS=
EXTRA_LIBS=
EXTRA_INCLUDES=
--- 41,47
# Settings here have priority; If not set, Configure will attempt to guess
# the C compiler, looking for gcc first, then cc.
#
! EXTRA_CFLAGS=-DHTTPD_ROOT=\/users/src/a13b3\ -DDEBUG_CGI
-DDEBUG_SUGID_CONFIG -DSUEXEC_BIN=\/users/src/a13b3/sbin/suexec\
EXTRA_LDFLAGS=
EXTRA_LIBS=
EXTRA_INCLUDES=
***
*** 181,192
## STATUS=yes (see the Rules section near the start of this file) to allow
## full status information. Check conf/access.conf on how to enable this.
! # AddModule modules/standard/mod_status.o
## The Info module displays configuration information for the server and
## all included modules. It's very useful for debugging.
! # AddModule modules/standard/mod_info.o
## mod_include translates server-side include (SSI) statements in text files.
## mod_autoindex handles requests for directories which have no index file
--- 181,192
## STATUS=yes (see the Rules section near the start of this file) to allow
## full status information. Check conf/access.conf on how to enable this.
! AddModule modules/standard/mod_status.o
## The Info module displays configuration information for the server and
## all included modules. It's very useful for debugging.
! AddModule modules/standard/mod_info.o
## mod_include translates server-side include (SSI) statements in text files.
## mod_autoindex handles requests for directories which have no index file
diff -c --exclude=*.[oa] --recursive apache_1.3b3/src/main/util_script.c
a13b3/src/main/util_script.c
*** apache_1.3b3/src/main/util_script.cSun Nov 16 08:45:22 1997
--- a13b3/src/main/util_script.c Fri Feb 6 08:47:03 1998
***
*** 559,567
#endif
! API_EXPORT(int) call_exec(request_rec *r, char *argv0, char **env, int
shellcmd)
{
int pid = 0;
#if defined(RLIMIT_CPU) || defined(RLIMIT_NPROC) || \
defined(RLIMIT_DATA) || defined(RLIMIT_VMEM)
--- 559,569
#endif
suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures
Number: 1769 Category: suexec Synopsis: suexec too limited -- need per-directory control, more permissive directory structures Confidential: no Severity: serious Priority: medium Responsible:apache State: open Class: sw-bug Submitter-Id: apache Arrival-Date: Tue Feb 3 21:50:00 PST 1998 Last-Modified: Originator: [EMAIL PROTECTED] Organization: apache Release:1.3* Environment: any os/any compiler/etc. Description: I work with an ISP providing quite complex web app's, and rely heavily on the sugid patches to cgi (available up to 1.2b10) to configure what user a cgi is run as. Due to changes in Apache, sugid can't be implemented (as far as I can see) in 1.3, but the restrictions of suexec are too painful! We often have multiple applications running in subdirectories of a single cgi-bin, each with its own user (consider mail trapping, etc...). I don't want suppport necessarily, but am struggling with large scale hacking necessary to add per-directory control of what user/group a script is run as. Not to mention the requirement that all virtuals be in a single document space.. I am amazed that this is being accepted by folks. Am I missing something? That seems like a tremendously and unjustifiably restrictive requirement. How-To-Repeat: Fix: I'm currently digging through the code, but am still too clueless to suggest anything. I want suexec to be able to duplicate the abilities of sugid, if you are familiar with sugid... per-directory control of userid/groupid. I expect I'll have to hack the core to implement this functionality. Eeek! What I really want is a policy reading from the Apache folk saying We don't care about this problem, you're on your own or if I'm lucky here's some suggestions, go do it and send us the patches Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
Re: suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures
[In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] Synopsis: suexec too limited -- need per-directory control, more permissive directory structures Class-Changed-From-To: sw-bug-change-request Class-Changed-By: coar Class-Changed-When: Wed Feb 4 06:42:59 PST 1998
