miss handling of the SIGHUP signal for sshd when sshd is started with a relative path sshd_config file

[Damien Miller]

On Wed, 25 Feb 2009, Ben Lindstrom wrote:

> 
> On Feb 25, 2009, at 2:04 AM, ?? wrote:
> 
> >
> > Hi
> >
> > I am just porting ssh-5.2 to my HPUX system.
> >
> >
> > but while I'm doing it, I accidently  found a different handling of  
> > the sshd for the SIGHUP signal when it is started with a "./ 
> > sshd_config" and "/sshd_config".
> >
> > The problem is as following:
> >
> > root at sshpa6# uname -a
> > HP-UX sshpa6 B.11.31 U 9000/800 2404418693 unlimited-user license
> >
> > root at sshpa6# /opt/ssh/sbin/sshd -f ./sshd_config                   
> > ### ./sshd_config is a relative path
> > root at sshpa6# ps -ef|grep sshd
> >    root 12616     1  0 15:51:00 ?         0:00 /opt/ssh/sbin/sshd - 
> > f ./sshd_config
> >    root 12618 17401  0 15:51:03 pts/tb    0:00 grep sshd
> > root at sshpa6# kill -HUP 12616
> > root at sshpa6# ps -ef|grep sshd
> >    root 12620 17401  0 15:51:12 pts/tb    0:00 grep sshd        ###  
> > sshd is killed but not restarted as it should be.
> >
> > So is it a bug or a normal situation?
> >
> 
> If I had the venture a guess it is because ./xxx is a relative, and  
> after a chdir("/") it is no longer the same location when OpenSSH is - 
> HUP it no longer knows where the configuration file is and thus  
> terminates itself.
> 
> So yes, I would expect this behavior myself.
> 
> So the simply truth is you should always do:  /path/to/sshd -f /path/ 
> to/sshd_config

We use relative config paths for the regress tests IIRC, but perhaps we
could realpath() them first.

-d