Subject: Re: localtime and chroot issues
To: Ian Zagorskih <firstname.lastname@example.org>
From: Klaus Klein <email@example.com>
Date: 05/05/2004 22:21:22
On Wednesday 05 May 2004 05:41, Ian Zagorskih wrote:
> =F7 =D3=CF=CF=C2=DD=C5=CE=C9=C9 =CF=D4 4 =ED=C1=CA 2004 19:36 Klaus Klein=
> > On Tuesday 04 May 2004 14:14, Ian Zagorskih wrote:
> > [moved to tech-userlevel]
> > > Doing some transfers with TFTP and debugging some dummy 3d party TFTP
> > > client i fould quite an "odd" syslog behaviour: all tftpd records in
> > > syslog were in GMT rather in system's localtime (GMT+7). After a litt=
> > > research i found, that tftpd daemon runs as chroot-ed process in defa=
> > > /tftproot dir so of course it couldn't access /etc/localtime to get t=
> > > proper timezone information. Ok, i made a copy of localtime in tftpd's
> > > sandbox so it feels happy now.
> > This could also be worked around by issuing tzset() prior to
> > chroot()ing the tftpd process, possibly by doing so in tftpd, or
> > in openlog().
> Just made a little test: I call tzset() right before calling chroot(). Lo=
> like doing this way time zone information is stored in process's local=20
> storage so all works fine now.
> Should it be added into main sources tree ? At least as workaround.
I have done so.
> > > 2. Such trick when i have to make mirrowing of localtime [and others]
> > > file system variables can lead to the problem when i have a lot of ch=
> > > boxes. During server's re-configuration i can easily forget to update=
> > > example localtime of some chrooted client. On the other hand, such th=
> > > as time zone information is system wide so maybe it would be reasonab=
> > > to move it in sysctl like "kern.localtime" so i could setup this info=
> > > sysctl.conf and have it accessible system wide regadrless to the curr=
> > > root path ?
> > There's some prior art for providing the local domain log socket to
> > chroot()ed processes; see /etc/rc.d/syslogd.
> Not so bad workaround for syslogd but... It dosn't look to be too elegant=
> me :) IMHO of course.
Actually, I think it is a very elegant workaround since the amount of
catering to chroot()ed operation in application code is reduced thereby.