[RFC] Suexec On/Off directive

[Jeff Trawick <tr...@gmail.com>]

(This seems quite simple to me other than the question of
implementing-module, but perhaps those who are more suexec-aware have
concerns.)

If you specify "Suexec On":   Startup fails if the suexec binary is
bad/missing instead of proceeding with suexec disabled.
If you specify "Suexec Off":   Suexec is off even if the binary is
okay, so there's no need to rename it (and rename again after
installing a new version) to disable.
If you don't use the directive, the historical behavior is preserved:
suexec is on or off based on the existence and attributes of the
suexec binary.
The directive can only be used at global scope.

Note that existing module logic that looks at the suexec state in a
pre-config hook (running after mod_unix's pre-config hook) might see
that suexec is enabled even though this directive will turn it off.  I
don't think this is a practical concern, though.

Is there something special about the breakdown of suexec logic between
mod_unixd and mod_suexec?  Should this directive really be in
mod_unixd since it owns the global suexec_enabled flag?

Index: modules/generators/mod_suexec.c
===================================================================
--- modules/generators/mod_suexec.c     (revision 1032981)
+++ modules/generators/mod_suexec.c     (working copy)
@@ -55,6 +55,23 @@
     return mkconfig(p);
 }

+static const char *set_suexec(cmd_parms *cmd, void *dummy, int arg)
+{
+    const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+    if (err != NULL) {
+        return err;
+    }
+
+    if (!ap_unixd_config.suexec_enabled && arg) {
+        return "suEXEC isn't supported.  The suexec binary is missing "
+               "or has invalid attributes.";
+    }
+
+    ap_unixd_config.suexec_enabled = arg;
+    return NULL;
+}
+
 static const char *set_suexec_ugid(cmd_parms *cmd, void *mconfig,
                                    const char *uid, const char *gid)
 {
@@ -112,6 +129,8 @@
  */
 static const command_rec suexec_cmds[] =
 {
+    AP_INIT_FLAG("Suexec", set_suexec, NULL, RSRC_CONF,
+                 "Enable or disable suEXEC support"),
     /* XXX - Another important reason not to allow this in .htaccess is that
      * the ap_[ug]name2id() is not thread-safe */
     AP_INIT_TAKE2("SuexecUserGroup", set_suexec_ugid, NULL, RSRC_CONF,


-- 
Born in Roswell... married an alien...

Re: [RFC] Suexec On/Off directive

[Jeff Trawick <tr...@gmail.com>]

On Tue, Nov 9, 2010 at 2:18 PM, Stefan Fritsch <sf...@sfritsch.de> wrote:
>> Is there something special about the breakdown of suexec logic
>> between mod_unixd and mod_suexec?  Should this directive really be
>> in mod_unixd since it owns the global suexec_enabled flag?
>
> Since it seems you don't need mod_suexec to use suexec (mod_userdir is
> enough), I think it should be in mod_unixd. Alternatively, the setting
> of the suexec_enabled flag should be moved to mod_suexec, too.

funny, I have the same code in mod_unixd inside #if 0

(some effort on redistributing and/or consolidating various code in
mod_unixd/unixd/mod_suexec would be worthwhile)

Re: [RFC] Suexec On/Off directive

[Stefan Fritsch <sf...@sfritsch.de>]

On Tuesday 09 November 2010, Jeff Trawick wrote:
> (This seems quite simple to me other than the question of
> implementing-module, but perhaps those who are more suexec-aware
> have concerns.)
> 
> If you specify "Suexec On":   Startup fails if the suexec binary is
> bad/missing instead of proceeding with suexec disabled.
> If you specify "Suexec Off":   Suexec is off even if the binary is
> okay, so there's no need to rename it (and rename again after
> installing a new version) to disable.
> If you don't use the directive, the historical behavior is
> preserved: suexec is on or off based on the existence and
> attributes of the suexec binary.
> The directive can only be used at global scope.

+1

> Note that existing module logic that looks at the suexec state in a
> pre-config hook (running after mod_unix's pre-config hook) might
> see that suexec is enabled even though this directive will turn it
> off.  I don't think this is a practical concern, though.
> 
> Is there something special about the breakdown of suexec logic
> between mod_unixd and mod_suexec?  Should this directive really be
> in mod_unixd since it owns the global suexec_enabled flag?

Since it seems you don't need mod_suexec to use suexec (mod_userdir is 
enough), I think it should be in mod_unixd. Alternatively, the setting 
of the suexec_enabled flag should be moved to mod_suexec, too.