Bug 217317 - localtime() doesn't cache /etc/localtime contents, gets confused following chroot()
localtime() doesn't cache /etc/localtime contents, gets confused following ch...
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-11-26 19:01 EST by Philip Prindeville
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-27 04:52:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Sample test program. (223 bytes, text/plain)
2006-11-26 19:01 EST, Philip Prindeville
no flags Details

  None (edit)
Description Philip Prindeville 2006-11-26 19:01:47 EST
Description of problem:

In gssftpd (part of the krb5-workstation) RPM does a chroot() when an anonymous
login session is started. However, the logs it writes (the file is opened
previous to the chroot()) gets written with timestamps (from ctime() in

The problem is that all logs after the chroot() get written as GMT, since
ctime() no longer has access to the contents of /etc/localtime.

At a minimum, either a hook to prefect and store the contents of /etc/localtime
could be added, or else the man page could be explain the interaction of
chroot() with ctime(), and the importance of calling ctime() to prime its state
before the chroot().

Version-Release number of selected component (if applicable):


How reproducible:

Compile and run the attached file.  If compiled with -DBEFORE, it works
properly.  If compiled without it, it doesn't.  (Note: must be run as root
because of the chroot() in it.)
Actual results:

Sun Nov 26 23:54:44 2006

Expected results:

Sun Nov 26 16:54:44 2006

Additional info:
Comment 1 Philip Prindeville 2006-11-26 19:01:48 EST
Created attachment 142142 [details]
Sample test program.
Comment 2 Jakub Jelinek 2006-11-27 04:52:58 EST
Most of this is documented already in POSIX.
The "hook to prefetch /etc/localtime" is called tzset(3p), then there are several
functions which just use the timezone data (these do effectively an tzset only
if it hasn't been called yet in the current process, ctime is one of them) and
then other function where their 3p section man pages mention that they behave
as if they use tzset internally (e.g. localtime, these functions really do that).

If TZ env var is unset, tzset stats /etc/localtime and if it was called the
first time or if it changed since last call (this was added so that
changing timezone on a running system is possible without restarting everything),
it is reread (and if /etc/localtime is not valid, the default is TZ=GMT).

So, when using the chroot, preferrably link or bind mount /etc/localtime into
the chroot (e.g. system-config-date and /usr/sbin/tzdata-update copy
/etc/localtime over to /var/spool/postfix/etc/localtime if it existed previously
and had the same content as /etc/localtime), or tzset () before chrooting and
make sure you don't use any functions where documentation says it behaves as if
tzset () was called.
Comment 3 Philip Prindeville 2006-11-30 20:35:17 EST
Ok, does localtime_r() behave like localtime() in this respect?

Does ctime_r() behave local ctime()?

And does openlog() call tzset() to make itself chroot()-safe?  If not, it might
be worth changing it so that it does.

But I guess the more important issue, is that when it is called repeatedly (as
happens in glibc's syslog() -- since it calls localtime_r() and strftime_r()),
should it be idempotent?  If you call it outside the chroot() prison, and
tzset() succeeds, then you chroot() and call it again and it fails to find its
files... should failing cause it to clobber the previously good results it had
from before?

Seems self-defeating.

Note You need to log in before you can comment on or make changes to this bug.