You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Hyde <bh...@gensym.com> on 1998/05/06 22:34:48 UTC
chdir isn't thead specific
Re:
WIN32 1.3 FINAL RELEASE SHOWSTOPPERS:
* bad use of chdir in some places; it isn't thread-specific
First an enumeration of where chdir is used.
These are not an issue?
include/conf.h:637:#define chdir _chdir2
Part of the __EMX__ (aka OS/2)
main/http_main.c:2186: chdir(ap_coredump_dir);
Part of sig_coredump so not part of the Windows footprint.
main/http_main.c:2428: chdir("/");
ifndef WIN32 -- part of detach()
os/win32/service.c:91: chdir(buf);
for service_cd() -- intentional
support/suexec.c:408: * Use chdir()s and getcwd()s to avoid problems with symlinked
support/suexec.c:417: if (((chdir(target_homedir)) != 0) ||
support/suexec.c:418: ((chdir(USERDIR_SUFFIX)) != 0) ||
support/suexec.c:420: ((chdir(cwd)) != 0)) {
support/suexec.c:426: if (((chdir(DOC_ROOT)) != 0) ||
support/suexec.c:428: ((chdir(cwd)) != 0)) {
Not on windows?
include/compat.h:66:#define chdir_file ap_chdir_file
Humm...
main/util.c:495:API_EXPORT(void) ap_chdir_file(const char *file)
main/util.c:502: chdir(file);
main/util.c:507: chdir(buf);
All part of ap_chdir_file
These are an issue:
modules/standard/mod_cgi.c:318: ap_chdir_file(r->filename);
ap_chdir_file(r->filename);
if (!cld->debug)
ap_error_log2stderr(r->server);
ap_cleanup_for_exec();
child_pid = ap_call_exec(r, argv0, env, 0);
modules/standard/mod_include.c:610: ap_chdir_file(r->filename);
in include_cgi
modules/standard/mod_include.c:701: ap_chdir_file(r->filename);
in handle_include
modules/standard/mod_include.c:847: ap_chdir_file(r->filename);
modules/standard/mod_include.c:857: ap_chdir_file(r->filename);
in handle_exec
if (!strcmp(tag, "cmd")) {
...
if (include_cmd(parsed_string, r) == -1) {
...
}
/* just in case some stooge changed directories */
ap_chdir_file(r->filename);
}
else if (!strcmp(tag, "cgi")) {
...
if (include_cgi(parsed_string, r) == -1) {
...
}
/* grumble groan */
ap_chdir_file(r->filename);
}
modules/standard/mod_include.c:2082: ap_chdir_file(r->filename);
in send_parsed_content
...
ap_chdir_file(r->filename);
if (r->args) {
...
ap_escape_shell_cmd(r->pool, arg_copy) ...
}
...
Second, what to do...
A mutex that owns the current working directory looks necessary.
Revising all the subprocess command execution to take a
directory would also be good.
Thoughts, volunteers?
- ben hyde
Re: chdir isn't thead specific
Posted by Dean Gaudet <dg...@arctic.org>.
No, that would confuse people moving between systems. I think it's an all
or nothing thing... likely to be a nothing thing.
Dean
On Wed, 6 May 1998, Brian Behlendorf wrote:
> At 02:08 PM 5/6/98 -0700, Dean Gaudet wrote:
> >The CGI "spec" doesn't *require* the current directory to be changed in
> >this arcane manner. But it's likely there are scripts that assume it.
> >I'd be a lot happier if we could just say that CGIs need to do the chdir
> >themselves, they have the information they need in PATH_TRANSLATED I
> >believe.
>
> #ifdef MULTITHREAD, maybe?
>
> Brian
>
>
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> pure chewing satisfaction brian@apache.org
> brian@hyperreal.org
>
Re: chdir isn't thead specific
Posted by Brian Behlendorf <br...@hyperreal.org>.
At 02:08 PM 5/6/98 -0700, Dean Gaudet wrote:
>The CGI "spec" doesn't *require* the current directory to be changed in
>this arcane manner. But it's likely there are scripts that assume it.
>I'd be a lot happier if we could just say that CGIs need to do the chdir
>themselves, they have the information they need in PATH_TRANSLATED I
>believe.
#ifdef MULTITHREAD, maybe?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
pure chewing satisfaction brian@apache.org
brian@hyperreal.org
RE: chdir isn't thead specific
Posted by Dean Gaudet <dg...@arctic.org>.
Er, SCRIPT_FILENAME then, which is apache specific though... but it's set
to the same value which is passed to chdir_file().
Dean
On Thu, 7 May 1998, Andy Finkenstadt wrote:
> Definitely water under the bridge. Every script I write has a standard
> template, and it assumes that `pwd` returns the current directory of the
> script itself. There's no PATH_TRANSLATED for any script that doesn't have
> additional /path/components, and SCRIPT_NAME is in URI form, not an absolute
> pathname, so scripts that are mod_rewritten, or ScriptAliased, or in a
> user's directory don't have an Absolut path to the script.
>
> Andy
>
> -----Original Message-----
> From: new-httpd-owner@apache.org [mailto:new-httpd-owner@apache.org] On
> Behalf Of Ben Hyde
> Sent: Wednesday, May 06, 1998 5:44 PM
> To: new-httpd@apache.org
> Subject: Re: chdir isn't thead specific
>
> >The CGI "spec" doesn't *require* the current directory to be changed in
> >this arcane manner.
>
> Well that's water under the bridge. The spec is probably out of
> synch with practical reality at this point.
>
>
RE: chdir isn't thead specific
Posted by Andy Finkenstadt <an...@simutronics.com>.
Definitely water under the bridge. Every script I write has a standard
template, and it assumes that `pwd` returns the current directory of the
script itself. There's no PATH_TRANSLATED for any script that doesn't have
additional /path/components, and SCRIPT_NAME is in URI form, not an absolute
pathname, so scripts that are mod_rewritten, or ScriptAliased, or in a
user's directory don't have an Absolut path to the script.
Andy
-----Original Message-----
From: new-httpd-owner@apache.org [mailto:new-httpd-owner@apache.org] On
Behalf Of Ben Hyde
Sent: Wednesday, May 06, 1998 5:44 PM
To: new-httpd@apache.org
Subject: Re: chdir isn't thead specific
>The CGI "spec" doesn't *require* the current directory to be changed in
>this arcane manner.
Well that's water under the bridge. The spec is probably out of
synch with practical reality at this point.
Re: chdir isn't thead specific
Posted by Ben Hyde <bh...@pobox.com>.
Dean wrote
>On Wed, 6 May 1998, Ben Hyde wrote:
>> Second, what to do...
>>
>> A mutex that owns the current working directory looks necessary.
>>
>> Revising all the subprocess command execution to take a
>> directory would also be good.
Pesky amount of change this late in the game.
>Right, if it took a directory then on unix the chdir() could happen after
>the fork() and everything is all real simple. On NT... allow me to puke
>again.
brainwashing proceeds more smoothly on an empty stomach
>The CGI "spec" doesn't *require* the current directory to be changed in
>this arcane manner.
Well that's water under the bridge. The spec is probably out of
synch with practical reality at this point.
I wonder where the chdir to "/" done in the service_cd() falls on
the spectrum from "seemed like a good idea" to "world ends without it"?
If it's on the right then these other chdirs need to switch back
and we can't cache the last one usefully.
spawn_mutex is probably relevant.
- ben hyde
Re: chdir isn't thead specific
Posted by Brian Behlendorf <br...@hyperreal.org>.
At 03:44 PM 5/6/98 -0700, Dean Gaudet wrote:
>Nah well it doesn't bother me much. It's only WIN32 that has problems
>with it, and WIN32 is slow enough at CGI already... so...
How difficult is it going to be to serialize? Isn't it just a matter of
grabbing a mutex before the chdir() and releasing it after the exec()?
It seems like left as-is it could cause some problems for heavy CGI users;
for 1.3.0 we either serialize this or declare that win32 CGI's need to do
their own chdir's.
There may also be some fixes for CGI under Win32 on the way from a friend,
which involves some Win32 native calls replacing POSIX calls, that may be
worth delaying the release for.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
pure chewing satisfaction brian@apache.org
brian@hyperreal.org
Re: chdir isn't thead specific
Posted by Wan-Teh Chang <wt...@netscape.com>.
Dean Gaudet wrote:
> > Fork() is a Unixism. You can only implement a "create process" function in
> > a portable way, which maps to fork+exec on Unix and CreateProcess
> > on Win32.
>
> Oh I understand why :)
Sorry... Didn't mean to underestimate your understanding :-)
> I'm just saying that this (give the new process a
> specific current working directory) is something we'll have to do under
> the covers of NSPR.
>
> It could be done as a ProcessAttr -- which would be backwards compatible
> with current NSPR.
>
> From what Sam Robb says this should be easily doable for WIN32 as well.
>
> What do you think?
Yes, Win32's CreateProcess takes 10 arguments, including one "catch-all"
startupinfo structure, so it would be really odd if I could not set the current
directory
of the new process after being tortured with such an impossible to memorize
function prototype. Maybe that's why they like to use the Hungarian naming
convention
to reduce their memory burden.
We can add a new attribute to PRProcessAttr, which is an opaque structure.
We can add new fields to it without breaking backward compatibility.
Wan-Teh
My opinons are mine, not my employer's.
Re: chdir isn't thead specific
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 7 May 1998, Wan-Teh Chang wrote:
> Dean Gaudet wrote:
>
> > BTW, this is a case that we'd have to modify the NSPR libraries to deal
> > cleanly with, because they don't present fork() to the user.
>
> Fork() is a Unixism. You can only implement a "create process" function in
> a portable way, which maps to fork+exec on Unix and CreateProcess
> on Win32.
Oh I understand why :) I'm just saying that this (give the new process a
specific current working directory) is something we'll have to do under
the covers of NSPR.
It could be done as a ProcessAttr -- which would be backwards compatible
with current NSPR.
>From what Sam Robb says this should be easily doable for WIN32 as well.
What do you think?
Dean
Re: chdir isn't thead specific
Posted by Wan-Teh Chang <wt...@netscape.com>.
Dean Gaudet wrote:
> BTW, this is a case that we'd have to modify the NSPR libraries to deal
> cleanly with, because they don't present fork() to the user.
Fork() is a Unixism. You can only implement a "create process" function in
a portable way, which maps to fork+exec on Unix and CreateProcess
on Win32.
Wan-Teh (of the NSPR group)
Re: chdir isn't thead specific
Posted by Dean Gaudet <dg...@arctic.org>.
Nah well it doesn't bother me much. It's only WIN32 that has problems
with it, and WIN32 is slow enough at CGI already... so...
BTW, this is a case that we'd have to modify the NSPR libraries to deal
cleanly with, because they don't present fork() to the user.
Dean
On Wed, 6 May 1998, Ben Laurie wrote:
> Dean Gaudet wrote:
> > The CGI "spec" doesn't *require* the current directory to be changed in
> > this arcane manner. But it's likely there are scripts that assume it.
>
> There are. And CGI/1.2 is going to require it.
>
> > I'd be a lot happier if we could just say that CGIs need to do the chdir
> > themselves, they have the information they need in PATH_TRANSLATED I
> > believe.
>
> Too late, mate. Shoulda thought of that a few years ago.
>
> Cheers,
>
> Ben.
>
> --
> Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
> Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
> and Technical Director|Email: ben@algroup.co.uk |
> A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
> London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
>
Re: chdir isn't thead specific
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
> The CGI "spec" doesn't *require* the current directory to be changed in
> this arcane manner. But it's likely there are scripts that assume it.
There are. And CGI/1.2 is going to require it.
> I'd be a lot happier if we could just say that CGIs need to do the chdir
> themselves, they have the information they need in PATH_TRANSLATED I
> believe.
Too late, mate. Shoulda thought of that a few years ago.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: chdir isn't thead specific
Posted by Dean Gaudet <dg...@arctic.org>.
On Wed, 6 May 1998, Ben Hyde wrote:
> These are not an issue?
Right.
> These are an issue:
>
> modules/standard/mod_cgi.c:318: ap_chdir_file(r->filename);
> ap_chdir_file(r->filename);
> if (!cld->debug)
> ap_error_log2stderr(r->server);
> ap_cleanup_for_exec();
> child_pid = ap_call_exec(r, argv0, env, 0);
The chdir file there should only have to happen in the forked child...
except this is WIN32, and fork isn't. I don't see how to fix this without
serializing chdir calls. Yuck.
>
> modules/standard/mod_include.c:610: ap_chdir_file(r->filename);
> in include_cgi
Right same as above.
>
> modules/standard/mod_include.c:701: ap_chdir_file(r->filename);
> in handle_include
This one I don't understand at all. But I think it could be fixed by just
pasting pathnames together -- use ap_make_dirstr_parent and append the
filename to be looked up. I think it's just for #include file. I'd
rather see it die though.
> modules/standard/mod_include.c:847: ap_chdir_file(r->filename);
> modules/standard/mod_include.c:857: ap_chdir_file(r->filename);
> in handle_exec
> if (!strcmp(tag, "cmd")) {
> ...
> if (include_cmd(parsed_string, r) == -1) {
> ...
> }
> /* just in case some stooge changed directories */
> ap_chdir_file(r->filename);
> }
> else if (!strcmp(tag, "cgi")) {
> ...
> if (include_cgi(parsed_string, r) == -1) {
> ...
> }
> /* grumble groan */
> ap_chdir_file(r->filename);
> }
>
> modules/standard/mod_include.c:2082: ap_chdir_file(r->filename);
> in send_parsed_content
> ...
> ap_chdir_file(r->filename);
> if (r->args) {
> ...
> ap_escape_shell_cmd(r->pool, arg_copy) ...
> }
> ...
These all fall into the CGI case I think, and I think it's all overkill.
> Second, what to do...
>
> A mutex that owns the current working directory looks necessary.
>
> Revising all the subprocess command execution to take a
> directory would also be good.
Right, if it took a directory then on unix the chdir() could happen after
the fork() and everything is all real simple. On NT... allow me to puke
again.
The CGI "spec" doesn't *require* the current directory to be changed in
this arcane manner. But it's likely there are scripts that assume it.
I'd be a lot happier if we could just say that CGIs need to do the chdir
themselves, they have the information they need in PATH_TRANSLATED I
believe.
Dean