Mailing List Archive

/var/log/messages internal-sftp time stamp problem
Hi,

I've compiled and successfully installed openssh 5.2p1, having it
configured to chroot users and log to syslog. It was compiled on two
different systems/platforms (RHEL 5.1/i386 and Fedora10/86_64).

All works perfectly fine except one thing where I am not sure whether
it is my mistake somewhere or some sort of bug: time stams from
internal-sftp subsystem are one hour behind systems clock as if
internal-sftp subsystem would only observe UTC (GMT) time zone without
offset and taking into consideration currently set timezone (for
example mine is now GMT+1).

Is there anything oobvious I could have missed in configuration or it
is just lacking functionality in internal-sftp (by functionality I
would mean observing systems time zone settings - not sure sure if
this is something to do with chrooting)?

Thanks.

Syy
Re: /var/log/messages internal-sftp time stamp problem [ In reply to ]
Syy Bak wrote:
> I've compiled and successfully installed openssh 5.2p1, having it
> configured to chroot users and log to syslog. It was compiled on two
> different systems/platforms (RHEL 5.1/i386 and Fedora10/86_64).
>
> All works perfectly fine except one thing where I am not sure whether
> it is my mistake somewhere or some sort of bug: time stams from
> internal-sftp subsystem are one hour behind systems clock as if
> internal-sftp subsystem would only observe UTC (GMT) time zone without
> offset and taking into consideration currently set timezone (for
> example mine is now GMT+1).

What's probably happening is that the chroot lacks a data file that the
C library uses to convert the TZ string into a offset from UTC, probably
/etc/localtime. Try copying that into the chroot, and if that's not it
try strace'ing the chrooted process to see what it's looking for (eg
"strace -o trace=open $pid").

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Re: /var/log/messages internal-sftp time stamp problem [ In reply to ]
Syy Bak wrote:
> Is there anything oobvious I could have missed in configuration or it
> is just lacking functionality in internal-sftp (by functionality I
> would mean observing systems time zone settings - not sure sure if
> this is something to do with chrooting)?

If you're running the sshd from within the chroot, then the chroot likely needs
to be configured to use the same timezone as the rest of the system. Things
that may need to be copied into the chroot may include /etc/localtime and
/etc/timezone.

John
Re: /var/log/messages internal-sftp time stamp problem [ In reply to ]
Just to get an idea, which timezone are you (the servers) in?

Kosala

On Wed, Jun 3, 2009 at 7:42 PM, Syy Bak <syybak@googlemail.com> wrote:
> Hi,
>
> I've compiled and successfully installed openssh 5.2p1, having it
> configured to chroot users and log to syslog. It was compiled on two
> different systems/platforms (RHEL 5.1/i386 and Fedora10/86_64).
>
> All works perfectly fine except one thing where I am not sure whether
> it is my mistake somewhere or some sort of bug: time stams from
> internal-sftp subsystem are one hour behind systems clock as if
> internal-sftp subsystem would only observe UTC (GMT) time zone without
> offset and taking into consideration currently set timezone (for
> example mine is now GMT+1).
>
> Is there anything oobvious I could have missed in configuration or it
> is just lacking functionality in internal-sftp (by functionality I
> would mean observing systems time zone settings - not sure sure if
> this is something to do with chrooting)?
>
> Thanks.
>
> Syy
>



--
Kosala
--------------------------------------------
Disclaimer: Views expressed in this mail are my personal views and
they would not reflect views of the employer.
--------------------------------------------
blog.kosala.net
www.linux.lk/~kosala/
www.kosala.net
Re: /var/log/messages internal-sftp time stamp problem [ In reply to ]
On Wed, Jun 03, 2009 at 05:42:23PM +0100, Syy Bak wrote:
> internal-sftp subsystem are one hour behind systems clock as if
> internal-sftp subsystem would only observe UTC (GMT) time zone without

> not sure sure if
> this is something to do with chrooting)?

Running the internal sftp inside a chroot could definitely account for
that. Your operating system may have a file or a symbolic link
somewhere in /etc which determines the default time zone; or it may
just use the TZ environment variable. They're all different.

The absence of this inside the chroot would cause the chrooted processes
to act as though they're running in UTC.
Re: /var/log/messages internal-sftp time stamp problem [ In reply to ]
In the last episode (Jun 04), Greg Wooledge said:
> On Wed, Jun 03, 2009 at 05:42:23PM +0100, Syy Bak wrote:
> > internal-sftp subsystem are one hour behind systems clock as if
> > internal-sftp subsystem would only observe UTC (GMT) time zone without
> [...]
> > not sure sure if this is something to do with chrooting)?
>
> Running the internal sftp inside a chroot could definitely account for
> that. Your operating system may have a file or a symbolic link somewhere
> in /etc which determines the default time zone; or it may just use the TZ
> environment variable. They're all different.

Shouldn't sshd still have the timezone information from before it chrooted,
though? Internal-sftp doesn't exec a new process, so as long as it called
some function that read /etc/localtime before the chroot it should know the
correct timezone.

--
Dan Nelson
dnelson@allantgroup.com
Re: /var/log/messages internal-sftp time stamp problem [ In reply to ]
2009/6/4 Greg Wooledge <wooledg@eeg.ccf.org>:
> Running the internal sftp inside a chroot could definitely account for
> that.  Your operating system may have a file or a symbolic link
> somewhere in /etc which determines the default time zone; or it may
> just use the TZ environment variable.  They're all different.
>
> The absence of this inside the chroot would cause the chrooted processes
> to act as though they're running in UTC.
>

Hi Guys, thanks all of you for your input. Mistery solved.

It is enough to copy localtime into <chroot_dir>/etc and all is back
to normal and timestams are in correct timezone.

Cheers.
Syy