Looking into the code for apr_proc_detach(int daemonize), it appears
that chdir("/") is being run unconditionally.
Was there a specific reason that "/" is chosen?
I guess it's not much of a big deal, because you can chdir into the
directory it should be in after you detach, however, why is this forced
into the function to begin with?
It would appear to be an enhancement to leave it up to the developer
using the function to chdir into the desired directory before or after
apr_proc_detach() and not force them to chroot before the function call
or require them to chdir afterwards.
It's only 3 lines of code, and should have a minimal impact on users of
the function.
For software that parses configurations, then chroots into the required
path, this would be alright, assuming you start the process with
permission to chroot, and don't intend to reach out to other paths.
Otherwise, you are left to chdir back to the previous cwd.
At the moment, I am fine with using getcwd and chdir to get back to
where I started, however it does seem counter-intuitive.
So, I am guessing that this is the expected practice when calling this
function, correct? Any insight would be great and any other methods to
use with this function to get around it would be appreciated.
--- threadproc/unix/procsup.c 2011-10-15 16:31:55.000000000 -0500
+++ threadproc/unix/procsup-mod.c 2013-01-18 13:28:11.145182475 -0600
@@ -18,9 +18,6 @@
APR_DECLARE(apr_status_t) apr_proc_detach(int daemonize)
{
- if (chdir("/") == -1) {
- return errno;
- }
#if !defined(MPE) && !defined(OS2) && !defined(TPF) && !defined(BEOS)
/* Don't detach for MPE because child processes can't survive the death of
