From 065a64b3d254fd634205f3472e96a6e18a97faf8 Mon Sep 17 00:00:00 2001
From: dgaudet
-
- The wrapper will only execute if it is given the proper number of arguments. - The proper argument format is known to the Apache web server. If the wrapper - is not receiving the proper number of arguments, it is either being hacked, or - there is something wrong with the suEXEC portion of your Apache binary. --
- This is to ensure that the user executing the wrapper is truly a user of the system. --
- Is this user the user allowed to run this wrapper? Only one user (the Apache - user) is allowed to execute this program. --
- Does the target program contain a leading '/' or have a '..' backreference? These - are not allowed; the target program must reside within the Apache webspace. --
- Does the target user exist? --
- Does the target group exist? --
- Presently, suEXEC does not allow 'root' to execute CGI/SSI programs. --
- The minimum user ID number is specified during configuration. This allows you - to set the lowest possible userid that will be allowed to execute CGI/SSI programs. - This is useful to block out "system" accounts. --
- Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs. --
- The minimum group ID number is specified during configuration. This allows you - to set the lowest possible groupid that will be allowed to execute CGI/SSI programs. - This is useful to block out "system" groups. --
- Here is where the program becomes the target user and group via setuid and setgid - calls. The group access list is also initialized with all of the groups of which - the user is a member. --
- If it doesn't exist, it can't very well contain files. --
- If the request is for a regular portion of the server, is the requested directory - within the server's document root? If the request is for a UserDir, is the requested - directory within the user's document root? --
- We don't want to open up the directory to others; only the owner user may be able - to alter this directories contents. --
- If it doesn't exists, it can't very well be executed. --
- We don't want to give anyone other than the owner the ability to change the program. --
- We do not want to execute programs that will then change our UID/GID again. --
- Is the user the owner of the file? --
- suEXEC cleans the process' environment by establishing a safe execution PATH (defined - during configuration), as well as only passing through those variables whose names - are listed in the safe environment list (also created during configuration). --
- Here is where suEXEC ends and the target program begins. --
+ The wrapper will only execute if it is given the proper number of arguments. + The proper argument format is known to the Apache web server. If the wrapper + is not receiving the proper number of arguments, it is either being hacked, or + there is something wrong with the suEXEC portion of your Apache binary. ++
+ This is to ensure that the user executing the wrapper is truly a user of the system. ++
+ Is this user the user allowed to run this wrapper? Only one user (the Apache + user) is allowed to execute this program. ++
+ Does the target program contain a leading '/' or have a '..' backreference? These + are not allowed; the target program must reside within the Apache webspace. ++
+ Does the target user exist? ++
+ Does the target group exist? ++
+ Presently, suEXEC does not allow 'root' to execute CGI/SSI programs. ++
+ The minimum user ID number is specified during configuration. This allows you + to set the lowest possible userid that will be allowed to execute CGI/SSI programs. + This is useful to block out "system" accounts. ++
+ Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs. ++
+ The minimum group ID number is specified during configuration. This allows you + to set the lowest possible groupid that will be allowed to execute CGI/SSI programs. + This is useful to block out "system" groups. ++
+ Here is where the program becomes the target user and group via setuid and setgid + calls. The group access list is also initialized with all of the groups of which + the user is a member. ++
+ If it doesn't exist, it can't very well contain files. ++
+ If the request is for a regular portion of the server, is the requested directory + within the server's document root? If the request is for a UserDir, is the requested + directory within the user's document root? ++
+ We don't want to open up the directory to others; only the owner user may be able + to alter this directories contents. ++
+ If it doesn't exists, it can't very well be executed. ++
+ We don't want to give anyone other than the owner the ability to change the program. ++
+ We do not want to execute programs that will then change our UID/GID again. ++
+ Is the user the owner of the file? ++
+ suEXEC cleans the process' environment by establishing a safe execution PATH (defined + during configuration), as well as only passing through those variables whose names + are listed in the safe environment list (also created during configuration). ++
+ Here is where suEXEC ends and the target program begins. ++
@@ -257,7 +258,7 @@ section of this document. BACK TO CONTENTS
-Here's where we begin the fun. The configuration and installation of suEXEC is a four step process: edit the suEXEC header file, compile suEXEC, place the @@ -396,7 +397,7 @@ user shell, do so now and execute the following commands. BACK TO CONTENTS
-After properly installing the suexec wrapper executable, you must kill and restart the Apache server. A simple @@ -454,7 +455,7 @@ and the error_log for the server to see where you may have gone astray. BACK TO CONTENTS
-NOTE! This section may not be complete. For the latest revision of this section of the documentation, see the Apache Group's @@ -467,33 +468,33 @@ There are a few points of interest regarding the wrapper that can cause limitations on server setup. Please review these before submitting any "bugs" regarding suEXEC.
- For security and efficiency reasons, all suexec requests must - remain within either a top-level document root for virtual - host requests, or one top-level personal document root for - userdir requests. For example, if you have four VirtualHosts - configured, you would need to structure all of your VHosts' - document roots off of one main Apache document hierarchy to - take advantage of suEXEC for VirtualHosts. (Example forthcoming.) --
- This can be a dangerous thing to change. Make certain every - path you include in this define is a trusted - directory. You don't want to open people up to having someone - from across the world running a trojan horse on them. --
- Again, this can cause Big Trouble if you try - this without knowing what you are doing. Stay away from it - if at all possible. --
+ For security and efficiency reasons, all suexec requests must + remain within either a top-level document root for virtual + host requests, or one top-level personal document root for + userdir requests. For example, if you have four VirtualHosts + configured, you would need to structure all of your VHosts' + document roots off of one main Apache document hierarchy to + take advantage of suEXEC for VirtualHosts. (Example forthcoming.) ++
+ This can be a dangerous thing to change. Make certain every + path you include in this define is a trusted + directory. You don't want to open people up to having someone + from across the world running a trojan horse on them. ++
+ Again, this can cause Big Trouble if you try + this without knowing what you are doing. Stay away from it + if at all possible. ++
-- 2.47.2