incomplete and not backportable, fix it by introducing NOT_IN_DIR_CONTEXT and
restoring NOT_IN_DIR_LOC_FILE to its previous value.
Per ap_check_cmd_context(), NOT_IN_DIR_LOC_FILE actually/really means "not in
any directory context", while the definition itself does not include all the
existing directory contexts (e.g. <Limit>, or <Proxy> before r1740928).
This is a bit of a misnomer, at least, so instead of (ab)using it by adding the
missing contexts (in an incompatible way), let's define NOT_IN_DIR_CONTEXT to
really exclude all directory context (i.e. NOT_IN_DIR_LOC_FILE + NOT_IN_LIMIT +
NOT_IN_PROXY) and use it wherever NOT_IN_DIR_LOC_FILE was used.
This is by itself a major MMN bump (modules not compiled with this commit and
having directives checked against NOT_IN_DIR_LOC_FILE won't be caught the same
way by NOT_IN_DIR_CONTEXT in the new ap_check_cmd_context() code), but with the
below change, 2.4.x should work as before:
- if ((forbidden & NOT_IN_DIR_CONTEXT) == NOT_IN_DIR_CONTEXT) {
+ if ((forbidden & NOT_IN_DIR_LOC_FILE) == NOT_IN_DIR_LOC_FILE) {
if (cmd->path != NULL) {
return apr_pstrcat(cmd->pool, cmd->cmd->name, gt,
- " cannot occur within directory context", NULL);
+ " cannot occur within <Directory/Location/Files/Proxy> "
+ "section", NULL);
}
...
}
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1812193 13f79535-47bb-0310-9956-ffa450edef68
binary (Suexec Off), or force startup failure if suEXEC is required
but not supported (Suexec On). Change SuexecUserGroup to fail
startup instead of just printing a warning if suEXEC is disabled.
Additionally, ap_unixd_config.suexec_disabled_reason has a message,
suitable for logging/messaging, explaining why the feature isn't
available.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1033519 13f79535-47bb-0310-9956-ffa450edef68
that we get less than 20% of the NOT_IN_LIMIT rules correct.
<Limit > works in about 4 directive contexts and yet, we ignore
this fact for 100's of directives. Simply eliminate this
nonsense in anticipation of a 100% solution.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@645189 13f79535-47bb-0310-9956-ffa450edef68
It's totally unsafe to use apr_pool_userdata_setn() in the post_config
phase of a module, since on some platforms when the DSO gets reloaded
between phases, the data segment will be at a different address on the
second phase and the userdata_get() call will fail.
PR: 9413
Submitted by: Tsuyoshi Sasamoto <nazonazo@super.win.ne.jp>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95287 13f79535-47bb-0310-9956-ffa450edef68
uid per our convention. Therefore, bad things would happen (like we
wouldn't cd to the right directory).
Add a flag to the ap_unix_identity_t structure to indicate if we are in
a userdir - if so, prefix the ~.
(Modified by Justin, but Colm's patch pointed me in the right direction.)
PR: 7810
Submitted by: Colm <colmmacc@redbrick.dcu.ie>
Reviewed by: Justin Erenkrantz
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94791 13f79535-47bb-0310-9956-ffa450edef68
message that we had back in apache-1.3 and is still scattered throughout
our docs.
Unfortunately, when mod_suexec is a DSO we're going to get this thing
twice in our logs. I believe as a side effect of the load-unload-load
cycles of our DSOs we're losing the static data segment, which is where
the "didn't we already report this" flag lives.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92255 13f79535-47bb-0310-9956-ffa450edef68
accomplished by moving suexec out of it's own file and into unixd.[ch].
The problem was that suexec.c wasn't being linked into the server unless
a module was actually using ap_os_create_process. This is still not clean,
but it works now.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86772 13f79535-47bb-0310-9956-ffa450edef68
