Bug 864603 - systemd[1]: SELinux policy denies access. (cannot change timezone from gnome control center)
systemd[1]: SELinux policy denies access. (cannot change timezone from gnome ...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
:
: 861525 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-09 13:53 EDT by Steve Tyler
Modified: 2014-02-05 07:31 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 07:31:05 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/var/log/messages (87.14 KB, text/plain)
2012-10-09 13:54 EDT, Steve Tyler
no flags Details
/var/log/audit/audit.log (127.87 KB, text/plain)
2012-10-09 13:56 EDT, Steve Tyler
no flags Details

  None (edit)
Description Steve Tyler 2012-10-09 13:53:40 EDT
Description of problem:
After installing and updating, the timezone is incorrect. When I attempt to correct it with gnome-control-center, the change does not take effect. If I put selinux in permissive mode, the change does take effect. There are no AVC denials that are clearly related to this problem and only this one message from systemd:
systemd[1]: SELinux policy denies access.

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

firstboot-18.4-1.fc18.x86_64
selinux-policy-3.11.1-32.fc18.noarch
selinux-policy-devel-3.11.1-32.fc18.noarch
selinux-policy-targeted-3.11.1-32.fc18.noarch
system-config-date-1.9.68-1.fc18.noarch
systemd-194-1.fc18.x86_64
systemd-libs-194-1.fc18.x86_64
systemd-sysv-194-1.fc18.x86_64

Fedora-18-Beta-TC2-x86_64-Live-Desktop.iso
anaconda 18.14-1

How reproducible:
Always.

Steps to Reproduce:
1. Set the timezone to America/Los_Angeles during installation of gnome desktop.
2. After installing, but before rebooting:
   # chroot /mnt/sysimage
   # yum update
2. After rebooting and logging in, start gnome-control-center and click Date & Time:
   The timezone shows Europe/London.
3. Set the timezone to America/Los_Angeles and exit the gnome-control-center.
   /etc/localtime is for ET, not America/Los_Angeles or Europe/London:
   $ ls -lZ /etc/localtime
   $ zdump /etc/localtime
4. $ sudo setenforce permissive
5. Start gnome-control-center and set the timezone for America/Los_Angeles.
   The timezone is now for America/Los_Angeles:
   $ ls -lZ /etc/localtime
   $ zdump /etc/localtime

Command-line:
$ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom ~/xfr/fedora/F18/F18-Beta/TC2/Fedora-18-Beta-TC2-x86_64-Live-Desktop.iso -usb -vga qxl -boot menu=on
  
Actual results:

selinux is enforcing:
[joeblow@localhost xfr]$ ls -lZ /etc/localtime
-rw-r--r--. root root system_u:object_r:locale_t:s0    /etc/localtime
[joeblow@localhost xfr]$ zdump /etc/localtime
/etc/localtime  Tue Oct  9 13:17:26 2012 EDT

selinux is permissive:
[joeblow@localhost xfr]$ ls -lZ /etc/localtime
lrwxrwxrwx. root root system_u:object_r:etc_t:s0       /etc/localtime -> ../usr/share/zoneinfo/America/Los_Angeles
[joeblow@localhost xfr]$ zdump /etc/localtime
/etc/localtime  Tue Oct  9 10:19:53 2012 PDT

Expected results:
The timezone can be set from gnome-control-center with selinux in enforcing mode.

Additional info:

/etc/localtime is supposed to be a symlink:
Bug 863676 - /etc/localtime link overwritten with incorrect timezone file during firstboot
Comment 1 Steve Tyler 2012-10-09 13:54:50 EDT
Created attachment 624211 [details]
/var/log/messages
Comment 2 Steve Tyler 2012-10-09 13:56:12 EDT
Created attachment 624213 [details]
/var/log/audit/audit.log
Comment 3 Steve Tyler 2012-10-09 14:01:14 EDT
[Snippet from /var/log/messages]
Oct  9 10:17:56 localhost systemd[1]: Started Time & Date Service.
Oct  9 10:17:56 localhost systemd[1]: SELinux policy denies access.
Oct  9 10:17:56 localhost systemd-timedated[1991]: Failed to issue method call: Access denied
Oct  9 10:17:56 localhost systemd-timedated[1991]: Failed to determine whether NTP is enabled: Input/output error
Oct  9 10:17:56 localhost systemd[1]: systemd-timedated.service: main process exited, code=exited, status=1
Oct  9 10:17:56 localhost systemd[1]: Unit systemd-timedated.service entered failed state.
...
Oct  9 10:18:07 localhost systemd[1]: Starting Time & Date Service...
Oct  9 10:18:07 localhost systemd-timedated[2001]: /etc/localtime should be a symbolic link to a timezone data file in /usr/share/zoneinfo/.
Comment 4 Daniel Walsh 2012-10-09 14:26:40 EDT
The first bug is causing the second bug.  Since /etc/localtime is a file SELinux is preventing it from being written over.  If you remove the file or set it up as a link it should work fine.
Comment 5 Steve Tyler 2012-10-09 14:38:48 EDT
(In reply to comment #4)
> The first bug is causing the second bug.  Since /etc/localtime is a file
> SELinux is preventing it from being written over.  If you remove the file or
> set it up as a link it should work fine.

OK. So is this then NOTABUG?

Also, I didn't get any SELinux alerts for this, but I got several alerts for firewalld that occurred at about the same time. It would save a lot of my time if I could just use the automated reporting system ...
Comment 6 Steve Tyler 2012-10-10 00:04:45 EDT
(In reply to comment #4)
> ... If you remove the file or
> set it up as a link it should work fine.

I removed /etc/localtime and attempted to set the timezone from gnome-control-center. systemd did not create /etc/localtime:

Oct  9 22:30:34 localhost systemd[1]: Starting Time & Date Service...
Oct  9 22:30:34 localhost systemd-timedated[2156]: Failed to get target of /etc/localtime: No such file or directory
Comment 7 Daniel Walsh 2012-10-10 07:43:03 EDT
How about if you set the link correctly, does it work then?
Comment 8 Steve Tyler 2012-10-10 09:14:39 EDT
(In reply to comment #7)
> How about if you set the link correctly, does it work then?

That didn't work either. When g-c-c starts, it displays the timezone for Europe/London.

1.  rm /etc/localtime
2.  reboot
3.  start g-c-c
    displayed timezone is Europe/London
4.  unlock and set timezone to America/Los_Angeles
5.  close g-c-c
    /etc/localtime does not exist
6.  $ cd /etc
    $ sudo ln -s ../usr/share/zoneinfo/America/Los_Angeles localtime
    date shows PDT
7.  start g-c-c
    displayed timezone is Europe/London
    unlock and set timezone to America/Los_Angeles
8.  close g-c-c
    date shows PDT
9.  start g-c-c
    displayed timezone is Europe/London
10. close g-c-c without any changes
11. setenforce permissive
12. start g-c-c
    displayed timezone is America/Los_Angeles
    unlock and set timezone to Europe/Berlin
13. close g-c-c
    date shows CEST
    /etc/localtime links to ../usr/share/zoneinfo/Europe/Berlin
Comment 9 Steve Tyler 2012-10-10 09:46:36 EDT
The experiment in Comment 8 did not show whether g-c-c was in fact setting the timezone. Here, after manually creating the link to America/Los_Angeles, I tried setting the timezone to Asia/Tokyo from g-c-c. That didn't work.

1.  rm /etc/localtime
2.  reboot
    date shows UTC
3.  start g-c-c
    displayed timezone is Europe/London
4.  close g-c-c without any changes
5.  $ cd /etc
    $ sudo ln -s ../usr/share/zoneinfo/America/Los_Angeles localtime
    date shows PDT
6.  start g-c-c
    displayed timezone is Europe/London
7.  unlock and set timezone to Asia/Tokyo
8.  close g-c-c
    date shows PDT
10. setenforce permissive
11. start g-c-c
    displayed timezone is America/Los_Angeles
    unlock and set timezone to Asia/Tokyo
12. close g-c-c
    date shows JST
    /etc/localtime links to ../usr/share/zoneinfo/Asia/Tokyo
Comment 10 Steve Tyler 2012-10-11 14:37:55 EDT
This looks like a duplicate:
Bug 861525 - Could not set system timezone in date & time
Comment 11 Daniel Walsh 2012-10-11 22:26:29 EDT
*** Bug 861525 has been marked as a duplicate of this bug. ***
Comment 12 Fedora End Of Life 2013-12-21 04:05:11 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 13 Fedora End Of Life 2014-02-05 07:31:08 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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