Bug 1190377 - SELinux is preventing polkitd from 'read' accesses on the lnk_file localtime.
Summary: SELinux is preventing polkitd from 'read' accesses on the lnk_file localtime.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: timedatex
Version: 22
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Lichvar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker abrt_hash:abf2c2a2753...
: 1210045 1211766 1213574 1213576 1213577 (view as bug list)
Depends On:
Blocks: F22FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2015-02-07 19:36 UTC by Adam Williamson
Modified: 2015-05-12 20:40 UTC (History)
24 users (show)

Fixed In Version: timedatex-0.3-1.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-12 20:40:26 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1219718 'unspecified' 'CLOSED' 'matchpathcon_init_prefix() does not behave as advertised' 2019-11-26 20:32:06 UTC

Internal Links: 1219718

Description Adam Williamson 2015-02-07 19:36:22 UTC
Description of problem:
Happens on first boot after install from 2015-02-07 Rawhide Workstation x86_64 live nightly.
SELinux is preventing polkitd from 'read' accesses on the lnk_file localtime.

*****  Plugin catchall_labels (83.8 confidence) suggests   *******************

If you want to allow polkitd to have read access on the localtime lnk_file
Then you need to change the label on localtime
Do
# semanage fcontext -a -t FILE_TYPE 'localtime'
where FILE_TYPE is one of the following: admin_home_t, bin_t, boot_t, cache_home_t, cert_t, config_home_t, config_usr_t, data_home_t, dbus_home_t, device_t, devlog_t, etc_runtime_t, etc_t, file_context_t, fonts_cache_t, fonts_t, gconf_home_t, gkeyringd_gnome_home_t, gnome_home_t, gstreamer_home_t, icc_data_home_t, ld_so_t, lib_t, locale_t, man_cache_t, man_t, net_conf_t, postfix_postdrop_t, proc_t, root_t, rpm_script_tmp_t, security_t, shell_exec_t, src_t, sssd_var_lib_t, sysfs_t, system_conf_t, system_db_t, textrel_shlib_t, tmp_t, usr_t, var_run_t, var_t. 
Then execute: 
restorecon -v 'localtime'


*****  Plugin catchall (17.1 confidence) suggests   **************************

If you believe that polkitd should be allowed read access on the localtime lnk_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep polkitd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:policykit_t:s0
Target Context                system_u:object_r:default_t:s0
Target Objects                localtime [ lnk_file ]
Source                        polkitd
Source Path                   polkitd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-110.fc22.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.19.0-0.rc7.git2.1.fc22.x86_64 #1
                              SMP Fri Feb 6 08:39:13 UTC 2015 x86_64 x86_64
Alert Count                   1
First Seen                    2015-02-07 11:34:22 PST
Last Seen                     2015-02-07 11:34:22 PST
Local ID                      e76454f5-0525-476d-b2b1-8ceedc53e7c4

Raw Audit Messages
type=AVC msg=audit(1423337662.636:568): avc:  denied  { read } for  pid=729 comm="polkitd" name="localtime" dev="dm-1" ino=913367 scontext=system_u:system_r:policykit_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0


Hash: polkitd,policykit_t,default_t,lnk_file,read

Version-Release number of selected component:
selinux-policy-3.13.1-110.fc22.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.19.0-0.rc7.git2.1.fc22.x86_64
type:           libreport

Comment 1 Adam Williamson 2015-02-07 19:39:01 UTC
There are four similar denials ('read access on the localtime lnk_file') for useradd, gdm-session-wor, spice-vdagentd and cupsd:

type=AVC msg=audit(1423337692.633:575): avc:  denied  { read } for  pid=1803 comm="cupsd" name="localtime" dev="dm-1" ino=913367 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0

type=AVC msg=audit(1423337660.929:541): avc:  denied  { read } for  pid=716 comm="spice-vdagentd" name="localtime" dev="dm-1" ino=913367 scontext=system_u:system_r:vdagent_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0

type=AVC msg=audit(1423337657.775:540): avc:  denied  { read } for  pid=1301 comm="gnome-session" name="localtime" dev="dm-1" ino=913367 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0

type=AVC msg=audit(1423337655.292:528): avc:  denied  { read } for  pid=1583 comm="usermod" name="localtime" dev="dm-1" ino=913367 scontext=system_u:system_r:useradd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0

Proposing as a Final blocker, criterion "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop." - https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#SELinux_and_crash_notifications

Comment 2 Dan Mossor [danofsatx] 2015-02-09 18:02:19 UTC
Discussed at 02-09-2015 Blocker Review Meeting:
http://meetbot.fedoraproject.org/fedora-blocker-review/2015-02-09/fedora-blocker-review.2015-02-09-17.00.log.txt

AcceptedBlocker for Final - This is a clear violation of the Final criterion: "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."

Comment 3 Mike Ruckman 2015-02-09 20:58:03 UTC
I didn't see any denials after installing and booting the 0207 nightly [0] in a vm. 

selinux-policy-3.13.1-110.fc22.noarch

[0] https://kojipkgs.fedoraproject.org/work/tasks/5965/8855965/Fedora-Live-Workstation-x86_64-rawhide-20150207.iso

Comment 4 Lukas Vrabec 2015-02-10 15:48:30 UTC
I also test it, I don't see any denials.

Comment 5 Jaroslav Reznik 2015-03-03 16:51:21 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 6 Lukas Vrabec 2015-04-15 14:28:18 UTC
*** Bug 1211766 has been marked as a duplicate of this bug. ***

Comment 7 Lukas Vrabec 2015-04-22 10:27:44 UTC
*** Bug 1213577 has been marked as a duplicate of this bug. ***

Comment 8 Lukas Vrabec 2015-04-22 10:47:02 UTC
*** Bug 1213574 has been marked as a duplicate of this bug. ***

Comment 9 Lukas Vrabec 2015-04-22 10:47:25 UTC
*** Bug 1213576 has been marked as a duplicate of this bug. ***

Comment 10 Lukas Vrabec 2015-04-22 10:59:23 UTC
Adding Systemd guys, 

Any help here? 

Question is, if this issue is also in fresh install of fedora, or just after upgrade.

Comment 11 Lukas Vrabec 2015-04-22 11:57:21 UTC
Oh, I see, it was during live CD

Comment 12 Miroslav Grepl 2015-04-27 09:34:31 UTC
Are we able to get it again?

Comment 13 Lukas Vrabec 2015-04-27 09:37:35 UTC
*** Bug 1210045 has been marked as a duplicate of this bug. ***

Comment 14 Lukas Vrabec 2015-04-27 10:36:54 UTC
Here we get some hint: https://bugzilla.redhat.com/show_bug.cgi?id=1210045#c5

Comment 15 Ervin 2015-05-02 19:10:46 UTC
Description of problem:
I changed the time settings to use my timezone. 
Then selinux reported this action. 

Version-Release number of selected component:
selinux-policy-3.13.1-119.fc22.noarch

Additional info:
reporter:       libreport-2.5.0
hashmarkername: setroubleshoot
kernel:         4.0.0-0.rc5.git4.1.fc22.x86_64
type:           libreport

Comment 16 Zbigniew Jędrzejewski-Szmek 2015-05-04 05:42:34 UTC
It seems that the file has context system_u:object_r:default_t:s0, but it should be locale_t.

Here I have:

$ ls -lZ /etc/localtime
lrwxrwxrwx. 1 root root system_u:object_r:locale_t:s0 38 Apr 12 18:04 /etc/localtime -> ../usr/share/zoneinfo/America/New_York

restorecon does not complain, so I assume that this is the correct context.

The cause of the denial is pretty obvious, and it seems to be correct in the circumstances. The question is where the context was set.

timedatectl, i.e. systemd-timedated, seems to set the context correctly to locale_t. I just checked to make sure, and the context of the target file does not matter (/usr/share/zoneinfo/...). So it seems that whoever created the link is guilty. In 1210045#c5 g-i-s was mentioned. I think it calls org.freedesktop.timedate1 method SetTime directly over dbus, so it cannot influence the context of the symlink in any way. anaconda will also create the symlink.

Would it be possible for somebody with an affected system to check the timestamp on the file, and say whether it was created by anaconda during installation, or after the start of the first boot?

Comment 17 Adam Williamson (Fedora) 2015-05-04 17:16:06 UTC
We need someone to provide the info requested by Zbigniew in #c16, thanks!

Comment 18 Zbigniew Jędrzejewski-Szmek 2015-05-04 18:00:51 UTC
I made an installation using Fedora-Workstation-netinst-x86_64-22_TC1.iso, and the context is correct. So I cannot reproduce this.

Comment 19 Adam Williamson 2015-05-04 18:59:56 UTC
zbigniew: well, the comment linked in comment #14 says they only saw the bug with i686 and creating a user with g-i-s. though I don't see how the arch could be involved.

Comment 20 Dan Mossor [danofsatx] 2015-05-04 19:27:45 UTC
Tested F22 TC1 i686 build. Installed from Live Workstation ISO and hit this bug.

Steps to reproduce:
1. Install 32 bit version
2. Do not create user in Anaconda
3. Create User in G-I-S
4-a. Change time zone in G-I-S
4-b. Change time zone after G-I-S through system settings
5. Receive the SELinux AVC pop up.

The AVC will be attached next.

Comment 21 Adam Williamson 2015-05-04 19:28:54 UTC
The specific information Zbigniew needs is in #c16 - he needs to know whether the file was created by anaconda or by g-i-s, which you can tell from the timestamp if you kept notes of the install timings...

Comment 22 Dan Mossor [danofsatx] 2015-05-05 13:14:58 UTC
It appears the link was created by G-I-S - install was completed at 15:11, the timestamp on the link is 15:21. /etc/localtime is a link to a time zone file in /usr/share/zoneinfo/, which in this specific case for testing is /usr/share/zoneinfo/America/Indiana/Vevay and has a time stamp of April 16.

[root@localhost ~]# ls -alZ /etc/localtime 
lrwxrwxrwx. 1 root root system_u:object_r:default_t:s0 43 May  4 15:21 /etc/localtime -> ../usr/share/zoneinfo/America/Indiana/Vevay
[root@localhost ~]# ls -alZ ../usr/share/zoneinfo/America/Indiana/Vevay
-rw-r--r--. 1 root root system_u:object_r:locale_t:s0 1423 Apr 16 23:18 ../usr/share/zoneinfo/America/Indiana/Vevay

Comment 23 Zbigniew Jędrzejewski-Szmek 2015-05-05 20:23:59 UTC
It seems that this indeed a systemd problem. Patch coming up.

Comment 24 Zbigniew Jędrzejewski-Szmek 2015-05-06 01:06:55 UTC
This strange feeling when a binary launched directly behaves differently then when launched through a dbus function call... what is going on ... insert print ... no effect ... insert sleep(5) ... no effect ... check timestamps ... everything OK ... set debug mode in PID1 ... oh, different service.

Comment 25 Miroslav Lichvar 2015-05-06 09:13:42 UTC
Ok, I managed to reproduce this with F22 beta3 i686 live install.

When stracing timedatex, I can see it is indeed setting the context to system_u:object_r:default_t:s0. I compared the strace output to one created on another system and it seems the problem is missing /etc/selinux/targeted/contexts/files/file_contexts.bin.

Reinstalling the selinux-policy{,-targeted} packages created that file and fixed the problem with timedatex setting incorrect context.

Why was the file missing?

FWIW, the timedatex code just calls matchpathcon() + lsetfilecon().

Comment 26 Adam Williamson 2015-05-06 16:18:23 UTC
This could be a live image compose issue. The logs have these lines:

mount: mount point /var/tmp/imgcreate-oAAcNS/install_root/sys/fs/selinux/load does not exist
/sbin/setfiles:  /var/tmp/imgcreate-oAAcNS/install_root is not located in /etc/selinux/targeted/contexts/files/file_contexts
/sbin/setfiles:  /var/tmp/imgcreate-oAAcNS/install_root/var is not located in /etc/selinux/targeted/contexts/files/file_contexts
/sbin/setfiles:  /var/tmp/imgcreate-oAAcNS/install_root/var/cache is not located in /etc/selinux/targeted/contexts/files/file_contexts
/sbin/setfiles:  /var/tmp/imgcreate-oAAcNS/install_root/var/log is not located in /etc/selinux/targeted/contexts/files/file_contexts
/sbin/setfiles:  /var/tmp/imgcreate-oAAcNS/install_root/boot is not located in /etc/selinux/targeted/contexts/files/file_contexts
/sbin/setfiles:  /var/tmp/imgcreate-oAAcNS/install_root/etc is not located in /etc/selinux/targeted/contexts/files/file_contexts
/sbin/setfiles:  /var/tmp/imgcreate-oAAcNS/install_root/etc/sysconfig is not located in /etc/selinux/targeted/contexts/files/file_contexts
/sbin/setfiles:  /var/tmp/imgcreate-oAAcNS/install_root/etc/sysconfig/mkinitrd is not located in /etc/selinux/targeted/contexts/files/file_contexts
/sbin/setfiles:  /var/tmp/imgcreate-oAAcNS/install_root/etc/dracut.conf.d is not located in /etc/selinux/targeted/contexts/files/file_contexts
/sbin/setfiles:  /var/tmp/imgcreate-oAAcNS/install_root/etc/dracut.conf.d/02livecd.conf is not located in /etc/selinux/targeted/contexts/files/file_contexts
/sbin/setfiles:  /var/tmp/imgcreate-oAAcNS/install_root/lost+found is not located in /etc/selinux/targeted/contexts/files/file_contexts
/sbin/setfiles:  /var/tmp/imgcreate-oAAcNS/install_root/dev is not located in /etc/selinux/targeted/contexts/files/file_contexts

though they appear in both x86_64 and i686 logs, so not sure why the bug would only affect i686.

https://koji.fedoraproject.org/koji/taskinfo?taskID=9592150 (x86_64)
https://koji.fedoraproject.org/koji/taskinfo?taskID=9592148 (i686)

mock_output.log is the most useful. Adding bcl and dennis.

Comment 27 Miroslav Lichvar 2015-05-07 09:01:47 UTC
(In reply to Adam Williamson from comment #26)
> though they appear in both x86_64 and i686 logs, so not sure why the bug
> would only affect i686.

I tried it again with x86_64 live install and the .bin files were missing there too. But I'm not sure if I saw the timezone selection dialog, does this depend on network connectivity and successful geo lookup?

The context of /etc/localtime was ok until I changed the timezone with timedatectl. Then I upgraded the selinux policy packages, which created the missing .bin files and another change of timezone with timedatectl fixed the context of /etc/localtime.

Comment 28 Adam Williamson 2015-05-07 16:03:07 UTC
I think I know what's causing the setfiles errors, at least:

https://github.com/SELinuxProject/selinux/commit/219eea83cea9336fc61ee6def5e114067e0c5040

we need that fix in policycoreutils on the live compose host. Whether that's what's causing this bug, I'm not entirely sure - but it should be easy enough to test. I'll see if I can do it.

Comment 29 Adam Williamson 2015-05-07 16:56:54 UTC
So, that fix was actually backported to policycoreutils yesterday. Building with the updated policycoreutils does prevent the setfiles errors showing up during image compose, but doesn't seem to fix this problem - /etc/selinux/targeted/contexts/files/file_contexts.bin is still missing, and changing the timezone with g-i-s or gnome-control-center still causes an AVC.

I do see one message when the selinux-policy package is installed during image creation:

  Installing: selinux-policy               ################### [ 786/1446] 
semodule: SELinux policy is not managed or store cannot be accessed.

that may be related somehow. Will investigate further.

Comment 30 Adam Williamson 2015-05-07 19:02:47 UTC
Another thing that doesn't fix it: selinux-policy-3.13.1-125.fc22 (tried building an image with it in the host and the compose, nope).

Comment 31 Adam Williamson 2015-05-07 20:24:01 UTC
So, here's a thing: on F21, file_contexts.bin is also not there after a clean live install - but this doesn't cause the bug. When changing the timezone, /etc/localtime remains correctly labelled. I believe the difference is that timedatex is a new thing in F22 - however timezone changes were handled before, I guess, didn't do it quite the same way as timedatex does.

Reinstalling selinux-policy triggers 'semodule -nB', which I believe generates the .bin files. This is because selinux-policy has a %triggerin script:

%triggerin -- pcre
selinuxenabled && semodule -nB
exit 0

a funny thing is that this %triggerin is defined inside the %if %{BUILD_TARGETED} block in the spec, but the script itself is for selinux-policy , not selinux-policy-targeted. Kinda odd. Not sure whether that's intentional or a mistake. (per https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch10s02.html - "The %triggerin script is run when a given target package is installed or upgraded. The %triggerin script is also run when your package is installed or upgraded, should the target package be already installed.")

Comment 32 Adam Williamson 2015-05-07 21:02:50 UTC
So here's an interesting thing (this is more or less what timedatex does, so far as I can figure out, translated into Python cos messing around with it interactively like this is easy):

BEFORE file_contexts.bin exists
-------------------------------

[root@localhost test]# cd /etc
[root@localhost etc]# python
Python 2.7.9 (default, Apr 15 2015, 12:07:52) 
[GCC 5.0.0 20150319 (Red Hat 5.0.0-0.21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import selinux
>>> selinux.matchpathcon_init_prefix(None, '../usr/share/zoneinfo')
0
>>> selinux.matchpathcon('/etc/localtime', 0)
[0, 'system_u:object_r:default_t:s0']
>>> 

Now we make file_contexts.bin exist
-----------------------------------

[root@localhost etc]# semodule -nB

and do it again:
----------------

[root@localhost etc]# python
Python 2.7.9 (default, Apr 15 2015, 12:07:52) 
[GCC 5.0.0 20150319 (Red Hat 5.0.0-0.21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import selinux
>>> selinux.matchpathcon_init_prefix(None, '../usr/share/zoneinfo')
0
>>> selinux.matchpathcon('/etc/localtime', 0)
[0, 'system_u:object_r:locale_t:s0']
>>> 

I wonder if that matchpathcon_init_prefix() is really correct - I'm pretty sure that's what timedatex does, but I think that '../' at the front probably makes it wrong. I suspect maybe instead of just calling `set_default_file_context(tmp, link);` in `finish_set_timezone()`, we should be dropping the LOCALTIME_TO_ZONEINFO_PATH from `link` before using it.

I wonder if it only *happens* to work for some reason if the .bin files exist (perhaps in that case libselinux really just loads the whole set because it's just as cheap either way, or something?)

I'll play around with this some more in a couple of hours.

Comment 33 Adam Williamson 2015-05-08 01:02:13 UTC
OK, so I think I'm more or less right. My timedatex PR:

https://github.com/mlichvar/timedatex/pull/1

fixes this, I tested. If anyone else wants to confirm, scratch build is http://koji.fedoraproject.org/koji/taskinfo?taskID=9682170 . There's one bit I still don't *entirely* understand, but hey, it definitely works. See the PR description for more details.

Comment 34 Adam Williamson 2015-05-08 01:55:58 UTC
I think there's a libselinux bug thrown into the mix here and somewhat confusing things. Reported as https://bugzilla.redhat.com/show_bug.cgi?id=1219718 .

Comment 35 Adam Williamson 2015-05-08 15:29:47 UTC
So far as what timedatex is actually doing here, one of the selinux devs suggested a way it can avoid setting contexts at all. So, here's what timedatex is trying to do:

ln -s /usr/share/zoneinfo/new/timezone /etc/localtime59078305 && mv /etc/localtime59078305 /etc/localtime

basically it wants to create the new timezone symlink with a temporary name and, if that works, rename it to the final name. The problem it has is that with current SELinux policy, when it creates /etc/localtime(random_integer), the context that file gets is not the correct context for /etc/localtime . SELinux doesn't relabel files on a move operation, so if it just does the above, /etc/localtime winds up with the wrong context.

Hence timedatex stuck in the code to get the correct context for /etc/localtime and apply it to the temporary symlink name after it's created but before the rename.

'tfirg' suggests that instead selinux-policy could have a rule that when timedatex creates a link in /etc, it gets the appropriate context. That will work fine so long as this is the only symlink timedatex needs to create in /etc . (I suppose we could also make the default context rule for /etc/localtime into a regex matching /etc/localtime* .) That way timedatex can get out of the context setting business entirely. As a general rule, apps aren't supposed to go around doing this sort of thing, it should usually be handled in SELinux policy somehow or other.

Comment 36 Stephen Smalley 2015-05-08 19:52:01 UTC
Just call restorecon('/etc/localtime') after rename.

Comment 37 Adam Williamson 2015-05-08 20:06:38 UTC
restorecon doesn't appear to be a part of the libselinux API so far as I can see. anyway, that seems racy - if something accesses the symlink after the rename but before the restorecon we'll get an AVC. something *does* seem to access it almost immediately after it's created.

Comment 38 Stephen Smalley 2015-05-08 20:09:02 UTC
Ok, then type_transition in policy is the right approach.

Comment 39 Fedora Update System 2015-05-11 08:23:24 UTC
timedatex-0.3-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/timedatex-0.3-1.fc22

Comment 40 Miroslav Lichvar 2015-05-11 08:26:43 UTC
Thanks for looking into this, Adam. The patch is now in timedatex-0.3-1.fc22.

BTW, a request for selinux policy for timedatex is in bug #1167289.

Comment 41 Adam Williamson 2015-05-11 16:28:35 UTC
for the record, the 0.3-1.fc22 fix is a patch I came up with to improve timedatex's context setting stuff. It does still set the context; we could adopt the 'fix it in the policy' approach and drop the context setting code later.

Comment 42 Fedora Update System 2015-05-11 19:06:09 UTC
Package timedatex-0.3-1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing timedatex-0.3-1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-7988/timedatex-0.3-1.fc22
then log in and leave karma (feedback).

Comment 43 Adam Williamson 2015-05-12 00:30:11 UTC
Built a live image with the update and confirmed the fix.

Comment 44 Fedora Update System 2015-05-12 20:40:26 UTC
timedatex-0.3-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.


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