Bug 193184

The duplicate messages will be removed (there is already upstream patch for
that) however some of the messages with the wrong timestamp are not duplicate
and there is currently no correct fix possible for this problem. Simply copying
/etc/localtime to the chroot is not possible because it would get out of sync if
the timezone on the computer is changed.
Maybe copying it on every sshd restart would be enough but I am not sure and it
would also contradict the /var/empty directory name.

It looks like this /etc/localtime issue comes out every time
one tries to use chrooted daemons.
The bind package copies the file on start.

This /etc/localtime mechanism is definitively not optimal,
for example there is another kind of "out of sync" problem, where
you upgrade the tzdata package, but you still use the
old /etc/localtime (see bug #186742).

Until now, nobody managed to find the "right" solution.

This is very annoying.  Some kind of fix is needed -- inconsistent time stamps
in logs obscure the true sequence of events.  Until a better fix is found, here
is an ugly solution:

Create /etc/sysconfig/sshd containing:

# Make sure that sshd gets the TZ environment variable

if [ -z "$TZ" ]; then
  . /etc/sysconfig/clock
  export TZ="$ZONE"
else
  export TZ
fi

# sshd runs chrooted from /var/empty/sshd but needs /etc/localtime

mkdir -p /var/empty/sshd/etc
chown root.root /var/empty/sshd
chown root.root /var/empty/sshd/etc
chmod 755 /var/empty/sshd/etc
chmod 555 /var/empty/sshd
cp -a -f /etc/localtime /var/empty/sshd/etc/

# /etc/localtime leads to timezone definitions under /usr/share/zoneinfo/$TZ
# Make them available under chroot as well

p="/usr/share/zoneinfo/$TZ"
if [ -f "$p" ]; then
  d=`dirname "$p"`
  f=`basename "$p"`
  mkdir -p "/var/empty/sshd$d"
  cp -a -f "$p" "/var/empty/sshd$p"
fi

FWIW, this bug is also at http://bugzilla.mindrot.org/show_bug.cgi?id=1214 with
"resolved worksforme" as follows:

-- quote --
Actually the TZ environment variable is there but because the privsep
slave is chrooted it does not have access to the /etc/localtime file
that tells how to interpret the TZ string.

The workaround is to create /etc/localtime inside the chroot ("mkdir
/var/empty/etc && cp -a /etc/localtime /var/empty/etc/" if you have the
chroot in the standard place).
-- unquote --

I just put in /etc/sysconfig/sshd ...

# workaround privsep localtime bug #1214
rm -rf /var/empty/sshd/etc
mkdir /var/empty/sshd/etc && cp -p /etc/localtime /var/empty/sshd/etc

... although if something like this is the official OpenSSH resolution, maybe it
could/should be moved into the init script.

openssh-4.3p2-4.1 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

openssh-4.3p2-4.1 seems to work well for me.

openssh-4.3p2-4.1 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Created attachment 137032 [details]
Fix "/etc/init.d/sshd" for symlinked "/etc/localtime"

It still does not work for me as I am using symlink for "/etc/localtime":
lrwxrwxrwx 1 root root 35 Jan  8  2006 /etc/localtime ->
../usr/share/zoneinfo/Europe/Prague
IIRC it was being used this way before, still I understand it may be considered
NOTABUG as the current FC configuration tools create it as a regular file.

I think bug #231326 is actually the correct fix for this issue.

Yes, that's even better way how to fix the problem.

(In reply to comment #10)
> Yes, that's even better way how to fix the problem.

Verified on
  sysklogd-1.4.2-2.fc7.i386
  openssh-4.5p1-4.fc7.i386
that /etc/localtime symlink bug reopened in my Comment 8 got fixed by sysklogd.

In this case /var/empty/sshd/etc/localtime should be removed from openssh.spec
together with the /etc/rc.d/init.d/sshd line
	cp -af /etc/localtime /var/empty/sshd/etc
to get unified behavior of /etc/localtime symlink vs. regular file machines.

Will be removed in the next rawhide build (openssh-4.7p1-3.fc8).