Bug 205330

Summary: Dovecot logs uses only UTC time
Product: Red Hat Enterprise Linux 4 Reporter: Matthew Sage <matt.sage>
Component: dovecotAssignee: Michal Hlavinka <mhlavink>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.4CC: mpoole, sputhenp, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-05 14:37:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matthew Sage 2006-09-06 02:46:39 UTC
Description of problem:
Dovecot uses UTC time to log login details if 'login_chroot' is turned on.

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

How reproducible:
Always

Steps to Reproduce:
1. Set logins to work in a chroot gaol - in /etc/dovecot.conf:
login_chroot = yes

Actual results:
Dovecot logging will use UTC time, ignoring /etc/localtime

Expected results:
Dovecot logging should respect /etc/localtime

Additional info:
This is caused because /etc/localtime is not accessible from the chroot gaol.

Previous workaround is to disable the login_chroot feature.

The following patch to the init.d script overcomes the problem:

*** /etc/init.d/dovecot.logfix 2006-09-06 12:14:34.000000000 +1000
--- /etc/init.d/dovecot  2006-02-08 10:57:35.000000000 +1100
***************
*** 21,36 ****
        RETVAL=$?
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/dovecot
-
-       # Check to see if login is chrooted
-       CHROOT_VAL=`grep ^login_chroot /etc/dovecot.conf | cut -f2 -d= | sed -e
's/^ *//'`
-       if [ "$CHROOT_VAL" != "no" ]; then
-               CHROOT_DIR=`grep ^login_dir /etc/dovecot.conf | cut -f2 -d= |
sed -e 's/^ *//'`
-               if [ -z "$CHROOT_DIR" ]; then
-                       # dovecot default
-                       CHROOT_DIR="/var/run/dovecot/login"
-               fi
-               mkdir $CHROOT_DIR/etc
-               cp /etc/localtime /$CHROOT_DIR/etc/
-       fi
        echo
  }
--- 21,24 ----

Comment 1 Dan Horák 2008-06-10 15:56:59 UTC
I don't think the initscript is the right place to prepare chrooted environment.
Better should be to add a standalone script (e.g. prepare-chroot.sh) into
/usr/share/doc/dovecot-*/ that the user configuring chrooted login can call.

Comment 2 Matthew Sage 2008-06-10 21:14:18 UTC
Although I agree in principle, the problem is that an admin wants to be able to
configure Dovecot and be able to start the service using '/sbin/service dovecot
start' (i.e. the useability of Dovecot should be the primary concern, not
ideological correctness).

This cannot happen the way you suggest because the description of the login_dir
variable states (from /etc/dovecot.conf),

# Directory where authentication process places authentication UNIX sockets
# which login needs to be able to connect to. The sockets are created when
# running as root, so you don't have to worry about permissions. Note that
# everything in this directory is deleted when Dovecot is started.

The localtime file is deleted each time Dovecot starts, so the only possible
place to set this up in the chroot environment is in the initscript, after the
daemon has been started.

Ugly, but...

Comment 3 Dan Horák 2008-06-11 10:32:36 UTC
Hmm, after looking at the issue more seriously, the update to the init script
looks like the right way.

Comment 4 RHEL Program Management 2008-10-31 16:41:39 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 5 Michal Hlavinka 2010-03-05 14:37:58 UTC
I'm sorry for not addressing the issue in RHEL-4. As dovecot
is not scheduled for update in RHEL-4.9, I'm closing that bugzilla WONTFIX. If
you are still experiencing the issue with RHEL-5, feel free to reopen it
against RHEL-5.