Bugzilla Bug 83260

Whenever I use Gnome tool for setting time, it chnages permission to
/etc/localtime so that only root can see it:

ls -l /etc/localtime
-rw-------  1 root root 1267 Feb 25 00:19 /etc/localtime

After this user sees time in UTC zone. Doing "chmod o+r /etc/localtime" fixes
the problem. I am seeing this in XFCE4, I have not tested it in GNOME.

Reproducible: Always
Steps to Reproduce:
1.Check current time and timezone as a user
2.Run Date and Time tool
3.Again check current time and timezone as a user

Actual Results:  
Timezone is set to UTC, and time is shifted by a differece between correct time
zone and UTC (5 hours in case of EST). This is because the permissions on
/etc/timezone are too restrictive, only root can read the file.

Expected Results:  
Timezone should not be changed.

Portage 2.0.51-r15 (default-linux/x86/2004.2, gcc-3.3.5,
glibc-2.3.4.20040808-r1, 2.6.10-ck5 i686)
=================================================================
System uname: 2.6.10-ck5 i686 AMD Athlon(TM) XP 2400+
Gentoo Base System version 1.5.3
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb  9 2005,
23:57:41)]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r1
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS="http://128.213.5.34/gentoo/ http://mirror.datapipe.net/gentoo
ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/
ftp://ftp.ussg.iu.edu/pub/linux/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 3dnow 3dnowex X aalib alsa apm artworkextra avi bash-completion berkdb
bitmap-fonts cdparanoia cdr crypt cups curl directfb divx4linux edl emboss
encode f77 fam fbcon fbdev fftw flac font-server foomaticdb fortran fpx gd gdbm
gif gnome gpm graphviz gstreamer gtk gtk2 gtkhtml guile hal imagemagick imlib
ipv6 java javascript jpeg libcaca libg++ libwww live lzo lzw-tiff mad mikmod
mmx
mng motif mozilla mozsvg mpeg msn nas ncurses network nls nptl nvidia oggvorbis
opengl pam pdflib perl plotutils png python quicktime readline real rtc sdl
slang spell sse ssl svg tcltk tcpd tetex theora tiff truetype truetype-fonts
type1-fonts usb v4l v4l2 wmf xml xml2 xmms xv xvid zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS

I can't reproduce this, my permissions are fine on /etc/localtime even after
using the time-admin tool.

joem@triforce ~ % ls -l /etc/localtime
-rw----r--  1 root root 1.3K Mar  1 16:41 /etc/localtime

This problem is related to user's umask setting, I have umask 077 in my .bashrc
and after disabling it (and having default 0022) it went away. 
The same bug was also filed in RedHat's bugzilla:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129876

Apparently, RedHat fixed it in December.

Closing per above.

Reopening, since it still does not work in Gentoo. RedHat may have fixed it (at
least according to their bugzilla), but it still does not work. Thus, this bug
is not resolved yet. 

@reporter: can you still reproduce this with 2.12?

(In reply to comment #5)
> @reporter: can you still reproduce this with 2.12?
> 

Yes, running current stable gnome (2.12.3), the error is still there. 

It seems that this issue is absolutely not handled by system-tools-backends
code (which is used by gnome-system-tools). I suggest to look for upstream bug
(on gnome bugzilla) and drop the link here.

(In reply to comment #7)
> It seems that this issue is absolutely not handled by system-tools-backends
> code (which is used by gnome-system-tools). I suggest to look for upstream bug
> (on gnome bugzilla) and drop the link here.
> 
I looked at gnome bugzilla, but could not find anything relevant.
The only bug report (and fix) I was able to find is the entry in RedHat
bugzilla already mentioned above:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129876

Created an attachment (id=101480) [details]
system-tools-backends-1.4.2-umask_for_localtime.patch

I couldn't reproduce this behaviour when running time-admin as a normal user
and then entering the root password. I only see it when I set the umask and
then run time-admin as root.

Anyway, looking at the source code, it's easy to see what's going on: the
backend first deletes the current localtime file and then it does a simple copy
operation without verifying the permissions on the file afterwards.

The attached patch reflects one way to fix this. You can apply it manually to
/usr/share/setup-tool-backends/scripts/time-conf or apply it inside
system-tools-backends's ebuild. Please test it and let us know if this resolves
what you describe.

Thanks.

How can I try out this patch, I mean how do I modify the system-tools-backends
(I hope this is the right one) ebuild to inlcude the patch when I reemerge it?

this version has been long masked but if any newer version still produce this
bug, please visit bug #214265.