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.
