Bug #222
closedssi virtual include uses wrong path
Description
I'm trying to execute something like in user home directory and lighttpd instead of referering to user's home directory eg. /home/user/www/cgi/counter.cgi it always refers to server document root (/var/www/html) eg.
2005-08-23 19:12:48: (mod_ssi.c.578) ssi: stating failed /var/www/html/~user/cgi/counter.cgi No such file or directory
-- gringo at slonko d0t net
Files
Updated by conny almost 19 years ago
"include virtual" works for me, but then instead scripts aren't executed!?
Updated by Anonymous over 18 years ago
In general virtual works, but not in combination with mod_userdir (that was my problem). I cannot make lighttpd to execute certain executable from user's home directory. I haven't tried the latest lighttpd from svn repository, but I believe it still does not work..
Some explanation to initial bug report:
/var/www/html - server document root
/home/user/www - user's homepage root
/home/user/www/cgi/counter.cgi - CGI I want to execute
/home/user/www/index.html - SHTML file containing ''
Normally I would expect that /home/user/www/cgi/counter.cgi would be executed by instead lighttpd looks for '/var/www/html/~user/cgi/counter.cgi' which isn't what I was looking for..
-- gringo
Updated by stbuehler about 16 years ago
- Target version changed from 1.4.20 to 1.4.21
Updated by icy almost 16 years ago
- Target version changed from 1.4.21 to 1.4.22
- Patch available set to No
Updated by stbuehler over 15 years ago
- Target version changed from 1.4.22 to 1.4.23
Updated by stbuehler over 15 years ago
- Assignee deleted (
jan) - Target version changed from 1.4.23 to 1.4.x
mod_ssi has low priority, especially if there is no patch.
Updated by gstrauss almost 9 years ago
untested, but would using con->physical.basedir instead of con->physical.doc_root work?
diff --git a/src/mod_ssi.c b/src/mod_ssi.c index f3f255b..b5fe3b5 100644 --- a/src/mod_ssi.c +++ b/src/mod_ssi.c @@ -537,7 +537,7 @@ static int process_ssi_stmt(server *srv, connection *con, plugin_data *p, const /* we have an uri */ - buffer_copy_buffer(p->stat_fn, con->physical.doc_root); + buffer_copy_buffer(p->stat_fn, con->physical.basedir); buffer_append_string_buffer(p->stat_fn, srv->tmp_buf); }
Updated by gstrauss over 8 years ago
Please note that other than for limited error handling, lighttpd does not have the concept of "internal subrequest" as Apache does. Adding such a feature is possible, but probably a substantial amount of work. SSI includes in lighttpd are currently limited to direct inclusion of file, not the output of processing the path through an "internal subrequest", so no "#include virtual" executing a CGI. SSI in lighttpd does not support "#exec cgi", either, though "#exec cmd" is supported. I mention this because one of the tests you suggested in your attached patch expect #include virtual=cgi.pl to work. (BTW, thanks for writing some tests!)
It should be simpler to patch lighttpd to support the common case of "#include virtual" of a file relative to a userdir from within that userdir. Alas, the patch I posted in a prior comment (above) is too simple. It does not remove /~username from paths. I have a slightly larger patch, but still localized in mod_ssi.c, which does so. If there is interest in this small extension to lighttpd SSI, I'll test and post the patch. However, it seems as if there might be a desire for a much more featureful mod_ssi.c, more than what a small patch can provide for this issue ticket.
Updated by gstrauss over 8 years ago
- Status changed from New to Patch Pending
- Target version changed from 1.4.x to 1.4.40
I am submitting a patch to adjust paths relative to changes made by mod_alias and mod_userdir.
This addresses the bug described by the ticket title "ssi virtual include uses wrong path"
Note: this still works only for direct file inclusion using #include virtual="..."
lighttpd mod_ssi does not perform an "internal subrequest" for the
virtual path, so things like virtual include of CGI are not supported
If interested in more featureful #include virtual functionality, please file a new issue as a feature request, not as a bug.
Updated by gstrauss over 8 years ago
- Status changed from Patch Pending to Fixed
- % Done changed from 0 to 100
Applied in changeset ede4d17913bfacfe865d158df5da0fd6ef8138b9.
Also available in: Atom