Subject: Re: localtime and chroot issues
To: Ian Zagorskih <ianzag@megasignal.com>
From: Klaus Klein <kleink@mibh.de>
List: tech-userlevel
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=
 =CE=C1=D0=C9=D3=C1=CC(a):
>=20
> > 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=
le
> > > research i found, that tftpd daemon runs as chroot-ed process in defa=
ult
> > > /tftproot dir so of course it couldn't access /etc/localtime to get t=
he
> > > 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().
>=20
> Just made a little test: I call tzset() right before calling chroot(). Lo=
oks=20
> like doing this way time zone information is stored in process's local=20
> storage so all works fine now.
>=20
> 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=
root
> > > boxes. During server's re-configuration i can easily forget to update=
 for
> > > example localtime of some chrooted client. On the other hand, such th=
ing
> > > as time zone information is system wide so maybe it would be reasonab=
le
> > > to move it in sysctl like "kern.localtime" so i could setup this info=
 in
> > > sysctl.conf and have it accessible system wide regadrless to the curr=
ent
> > > root path ?
> >
> > There's some prior art for providing the local domain log socket to
> > chroot()ed processes; see /etc/rc.d/syslogd.
>=20
> Not so bad workaround for syslogd but... It dosn't look to be too elegant=
 for=20
> 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.


=2D Klaus