Re: cfexecd chdir

[Tim Nelson]

On Sun, 2 Oct 2005, Jason Kim wrote:

> On Mon, 3 Oct 2005, Tim Nelson wrote:
>
> > On Wed, 28 Sep 2005, Jason Kim wrote:
> >
> > > I've noticed that cfexecd stays in the directory it was started in even when
> > > in daemon mode. May or may not have caused a problem I was experiencing with
> > > one of my shellcommands (the directory I started it in was subsequently
> > > deleted). I did a bunch of stuff at the same time, so I couldn't
> > > isolate/verify the fix, but chdir'ing to '/' is probably a good thing anyway.
> > > Simple patch follows.
> >
> >         Wouldn't we be better off with
> > --------------
> > struct passwd RootPassStruct;
> >
> > RootPassStruct =  getpwnam("root");
> > chdir(RootPassStruct->pw_dir);
> > --------------
>
> I suppose that works too... I thought that it was common practice to cd to
> '/' for any daemon simply because it is always guaranteed to be there.
> As the problem I had (though I'm still not 100% sure) had to do with
> cfexecd having a deleted directory as its cwd, I figured this would be the
> best fix.

	I figure getpwnam("root") should always exist too; I know on some 
systems it's "/" and on others, "/root".

        Just out of interest, I ran:
grep cd /etc/rc.d/init.d/*

	Of the two bits of software that actually did a "cd" in the init 
script, both did "cd /".  One of them is courier-authlib (3rd-party), but 
the other is xfs (comes with my Redhat system).  So maybe you're right :). 
I dunno.

--
Kind Regards,
 
Tim Nelson
Server Administrator
 
P: 03 9934 0888
F: 03 9934 0899
E: address@hidden
W: www.webalive.biz
 
WebAlive Technologies
Level 1, Innovation Building
Digital Harbour
1010 La Trobe Street
Docklands Melbourne VIC 3008

This email (including all attachments) is intended solely for the named 
addressee. It is confidential and may contain legally privileged information. If
you receive it in error, please let us know by reply email, delete it from your 
system and destroy any copies. This email is also subject to copyright. No
part of it should be reproduced, adapted or transmitted without the written 
consent of the copyright owner.

Emails may be interfered with, may contain computer viruses or other defects 
and may not be successfully replicated on other systems. We give no
warranties in relation to these matters. If you have any doubts about the 
authenticity of an email purportedly sent by us, please contact us immediately.