Bug 749516

Summary: kcm_clock (kcontrol/dateandtime) doesn't set persistent date
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: urgent    
Version: 16CC: awilliam, carl.gaudreault, dennis, dominick.grift, dwalsh, fedora, gansalmon, itamar, jakub, jarsmith, johannbg, jonathan, jones, jreznik, kdudka, kevin, kparal, lpoetter, ltinkl, madhu.chinakonda, maxamillion, metherid, mgrepl, mishu, mkrizek, mschmidt, notting, ovasik, p, plautrba, rdieter, rnovacek, ry, smparrish, systemd-maint, tflink, than, twaugh
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: RejectedBlocker
Fixed In Version: selinux-policy-3.10.0-61.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-29 21:00:23 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Kamil Páral 2011-10-27 06:25:40 EDT
Description of problem:
When I issue "date" command to set a different date, the date is changed in runtime, but it doesn't persistent through reboot. When checking in BIOS, the date was not changed there.

I tried to disable selinux, and lo and behold, the issue is still present. So it's not an selinux problem. I haven't found any error message in logs.

This problem also concerns KDE control center, the changed time doesn't persist through reboot either (maybe it calls "date" internally).

OTOH, GNOME control center sets the time correctly, it persists through reboot.

Tested in VM and on bare metal, in default and in minimal install.

Version-Release number of selected component (if applicable):
coreutils-8.12-2.fc16.i686
F16 TC2 i386 DVD default desktop

How reproducible:
100%

Steps to Reproduce:
1. set date through 'date' command
2. reboot
3. observe date
  
Actual results:
date is not changed

Expected results:
date is changed

Additional info:
Be sure not to change time more than 24 hours forward or backward when testing this. If you move the time more than 24 hours, you'll bump into bug #748920.
Comment 1 Kamil Páral 2011-10-27 06:32:39 EDT
Proposing as blocker due to this criterion:
"All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use"
https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria

Setting the time in the clock applet in KDE doesn't work, it fails that criterion. 

Let's wait for some developer input before voting on this, if possible.
Comment 2 Martin Krizek 2011-10-27 06:37:41 EDT
Confirming the issue, tested on KDE 4.7.2 (Fedora 16 Final TC2).
Comment 3 Ondrej Vasik 2011-10-27 06:49:03 EDT
If the time is set on runtime, than it is almost certainly not coreutils issue... I'd bet for glibc/kernel. Let's try glibc...
Comment 4 Adam Williamson 2011-10-27 11:54:44 EDT
systemd does have a few things that deal with time/date, note. it might be interfering somehow.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 5 Adam Williamson 2011-10-27 18:31:39 EDT
on blockeriness - well, the kde/gnome panels do *set* the clock, they do what they're supposed to do. the change not persisting across boots is not necessarily a bug in the panels. i'm not sure this is really serious enough to be a release blocker. i'm a light -1 on this unless anyone has some convincing arguments.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Adam Williamson 2011-10-28 01:49:42 EDT
CC for blocker votes.
Comment 7 Josh Boyer 2011-10-28 07:26:30 EDT
Wait, what?

If Gnome can set the time so that it's saved correctly, what is Gnome doing that date and KDE aren't?

Also, why is this against the kernel?  Do older kernels NOT exhibit this problem?  If so, which kernel "works"?
Comment 8 Josh Boyer 2011-10-28 07:31:09 EDT
Also, from what I remember 'date' doesn't write to the HW clock.  You need to use the hwclock command for that.  (I could be mistaken, since it's been years since I had to worry about this.)
Comment 9 Kamil Páral 2011-10-28 07:40:55 EDT
(In reply to comment #7)
> If Gnome can set the time so that it's saved correctly, what is Gnome doing
> that date and KDE aren't?

Probably calling a different glibc/kernel function? That's what I have been told by coreutils developer.

> Also, why is this against the kernel?  Do older kernels NOT exhibit this
> problem?  If so, which kernel "works"?

Yes, 'date' works in F15. Kernel 2.6.40-4.

(In reply to comment #6)
> CC for blocker votes.

I'm +1 NTH and in between on blocker. I'd love more developer feedback. Who can we bother directly?
Comment 10 Josh Boyer 2011-10-28 07:48:54 EDT
(In reply to comment #9)
> (In reply to comment #7)
> > If Gnome can set the time so that it's saved correctly, what is Gnome doing
> > that date and KDE aren't?
> 
> Probably calling a different glibc/kernel function? That's what I have been
> told by coreutils developer.
> 
> > Also, why is this against the kernel?  Do older kernels NOT exhibit this
> > problem?  If so, which kernel "works"?
> 
> Yes, 'date' works in F15. Kernel 2.6.40-4.

Can you install the 3.1 fc16 kernel on your F15 instance and see if it works?
Comment 11 Josh Boyer 2011-10-28 07:52:45 EDT
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #7)
> > > If Gnome can set the time so that it's saved correctly, what is Gnome doing
> > > that date and KDE aren't?
> > 
> > Probably calling a different glibc/kernel function? That's what I have been
> > told by coreutils developer.
> > 
> > > Also, why is this against the kernel?  Do older kernels NOT exhibit this
> > > problem?  If so, which kernel "works"?
> > 
> > Yes, 'date' works in F15. Kernel 2.6.40-4.
> 
> Can you install the 3.1 fc16 kernel on your F15 instance and see if it works?

And by "reboot" I'm guessing you mean a fully reboot cycle, either from the DE or from sudo reboot or sudo shutdown -r now and not 'reboot -f'.  Those do the reboot through the init system, so perhaps something in the shutdown path has changed between F15 and F16 as well.
Comment 12 Pádraig Brady 2011-10-28 08:04:13 EDT
`date -s` calls clock_settime (CLOCK_REALTIME, ...);
Perhaps that's broken?

Perhaps the settimeofday() is OK and gnome does that?

You could get `date` to try both of the about by recompiling with an adjusted lib/settime.c in coreutils.
Comment 13 Kamil Páral 2011-10-28 08:15:36 EDT
(In reply to comment #10)
> Can you install the 3.1 fc16 kernel on your F15 instance and see if it works?

Yes, that works. Using 'date' with kernel 3.1 fc16 on F15 correctly persists changed time.
Comment 14 Kamil Páral 2011-10-28 08:18:10 EDT
Setting the time using 'date' in F16 and using 'reboot -f' to bypass init system doesn't fix the problem, time is not persisted.
Comment 15 Josh Boyer 2011-10-28 08:46:42 EDT
(In reply to comment #13)
> (In reply to comment #10)
> > Can you install the 3.1 fc16 kernel on your F15 instance and see if it works?
> 
> Yes, that works. Using 'date' with kernel 3.1 fc16 on F15 correctly persists
> changed time.

OK.  Not a kernel problem then.

(In reply to comment #14)
> Setting the time using 'date' in F16 and using 'reboot -f' to bypass init
> system doesn't fix the problem, time is not persisted.

Right, I wouldn't expect that to work at all.  As I said before, I'm pretty sure hwclock needs to be called to make any changes done with date persist across a reset.

Since the F16 kernel works fine with the F15 reboot path, it's not a kernel problem.  Something else is different between the F15 and F16 shutdown paths.

I'm going to reassign to systemd for now, but that might not be the appropriate component either.
Comment 16 Adam Williamson 2011-10-28 14:48:21 EDT
Discussed at the 2011-10-28 blocker review meeting. This is rejected as a blocker; there's at least two workarounds, there's probably more, it can be fixed with an update, the behaviour may not even be incorrect in the first place, and the impact just doesn't seem to be all that world-rendingly important.
Comment 17 Bill Nottingham 2011-10-28 15:17:14 EDT
'date' has never set a persistent date. We at one point used to call hwclock on shutdown, but we do not any more (after all, you may not have a clean shutdown).

I suspect GNOME is using systemd's mechanism, which does make the call to synchronize to the hardware clock. KDE may not be (and date we know isn't).

In any case, this would appear to be a RFE for KDE and date, and not a bug.
Comment 18 Kevin Kofler 2011-10-28 15:42:15 EDT
Is it possible to enable sync-hwclock on the KDE spin?
Comment 19 Kevin Kofler 2011-10-28 22:16:39 EDT
So here is the relevant kde-workspace code:
https://projects.kde.org/projects/kde/kde-workspace/repository/show/kcontrol/dateandtime?rev=KDE%2F4.7

In particular, this function:
https://projects.kde.org/projects/kde/kde-workspace/repository/entry/kcontrol/dateandtime/helper.cpp?rev=KDE%2F4.7#L89
(which runs as root through KAuth/PolicyKit) actually sets the time and date. It does that by simply calling settimeofday.

kde-workspace clearly expects the time to get synced to the hardware clock automatically. So this systemd change:
http://cgit.freedesktop.org/systemd/commit/units?id=da2617378523e007ec0c6efe99d0cebb2be994e1
broke it.
Comment 20 Kevin Kofler 2011-10-28 22:37:44 EDT
To fix this, looks like calling "hwclock --systohc" after the settimeofday call is enough. I'm writing a patch.
Comment 22 Fedora Update System 2011-10-29 09:40:52 EDT
kdebase-workspace-4.7.2-12.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/kdebase-workspace-4.7.2-12.fc16
Comment 23 Kamil Páral 2011-10-29 12:04:59 EDT
Ondrej Vasik, should I clone this bug also for "date" command from coreutils, or you no longer intend to set the hardware clock with this command? That may confuse quite a few sysadmins, but it's true that 'hwclock' command is available for this purpose, people just probably don't know about it (I didn't).
Comment 24 Ondrej Vasik 2011-10-29 13:27:39 EDT
Kamil, do you think there is still a need for a clone bugzilla against date? I don't think so... It would mean change in date behaviour... As was already said by Bill Nottingham in c#17, date has never set persistent date - it was shutdown sequence which probably changed.

In date documentation is written that date sets system time - not hardware clock ... and as there is hwclock utility for operations with Hardware clock, it would be very hard to justify such change for the coreutils upstream (and probably even if you convince them, it will not be a default).
Comment 25 Kay Sievers 2011-10-30 22:59:10 EDT
We do not longer write the system time to the rtc at shutdown, tools need
to call hwclock --systohc to write it back to the hardware, if that's what
they want to do.

The system can not assume that the current time is 'better' than the time at startup, unless ntp is used, or the user explicitly told the system to write
back the time to hardware. It causes problems for systems booted from live CD
media, or for systems running with rtc in localtime.

The system only syncs to the hardware if ntp is used (the kernel does that
every 11 minutes), or if the D-Bus services are used (they write to the rtc
when setting the time).

This is not a bug, it should be fixed in the desktop tools.
Comment 26 Pádraig Brady 2011-10-31 07:48:46 EDT
Interesting. Thanks for the info Kay.
I'm a little surprised that a "hardware clock uses UTC" setting could not have been used to allow automatic adjustment of the hardware clock.
Anyway I'll update the coreutils info to differentiate the "system" and "hardware" clocks.
Comment 27 Kamil Páral 2011-10-31 09:03:46 EDT
I proposed some changes in coreutils (mainly man page adjustments) in bug 750244.
Comment 28 Lennart Poettering 2011-10-31 12:03:50 EDT
Yupp, I think it is a much better idea to sync the system clock down to the RTC at the time the user readjusts it, and not delay that until shut down. The GNOME clock utilities always synced the RTC right away, so I am a bit surprised that KDE didn't do this. But if it does that now this is great!
Comment 29 Kevin Kofler 2011-10-31 12:37:05 EDT
KDE's kcm_clock used to do this too in the distant past, but it got removed in 2008 because an upstream maintainer (Oswald "ossi" Buddenhagen) felt this is the shutdown scripts' job. I have readded it now (starting at 4.7.4 upstream, and kdebase-workspace-4.7.2-12.fc16 in Fedora), with ossi's approval (because the shutdown units don't do it anymore, so something has to do it).

That said, he had this to say in the patch review (in the "Ship it!" comment):
http://git.reviewboard.kde.org/r/102985/#review7743
> the patch itself is ok, but i find it questionable that systemd does not do
> that *too*. the argument "you could always have a crash anyway" seems rather
> bogus to me.
Comment 30 Kamil Dudka 2011-10-31 13:36:36 EDT
(In reply to comment #29)
> > the patch itself is ok, but i find it questionable that systemd does not do
> > that *too*.

Neither OpenRC does it by default:

http://roy.marples.name/projects/openrc/browser/conf.d/hwclock
Comment 31 Kamil Dudka 2011-10-31 13:46:16 EDT
Sorry, the link above is quite outdated.  This seems to be the up2date one:

http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=blob;f=conf.d/hwclock
Comment 32 Kay Sievers 2011-10-31 13:52:28 EDT
(In reply to comment #29)
> the patch itself is ok, but i find it questionable that systemd does not do
> that *too*. the argument "you could always have a crash anyway" seems rather
> bogus to me.

It's not about a crash, it's about a reliable time source. No system should
write back the system time to the hardware if it has no reliable time source.

NTP is a reliable time source, hence the kernel syncs ever 11th minute on
its own.

A user explicitly requesting the time to set and written to the hardware
is fine too.

Blindly fiddling with the RTC on every shutdown without a reliable time
reference is just plain wrong. The RTC is 1 sec granularity only, so every
second reboot might make the RTC drift a second, and all that adds up. It
just can not be right, so we need to leave it alone and don't fiddle with
things we can not do sufficiently correct.
Comment 33 Fedora Update System 2011-10-31 13:53:07 EDT
kde-settings-4.7-13.fc16.4, kdebase-workspace-4.7.2-13.fc16, kdelibs-4.7.2-5.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/kdebase-workspace-4.7.2-13.fc16,kdelibs-4.7.2-5.fc16,kde-settings-4.7-13.fc16.4
Comment 34 Rex Dieter 2011-10-31 15:13:18 EDT
Looks like this kcm_clock fix doesn't work, is running afoul of selinux somewhere.  will post a bug when I have time to extract details.
Comment 35 Kevin Kofler 2011-10-31 16:55:29 EDT
It might need a matching selinux-policy update. I need the AVCs.

(Grrr, now why are we enabling this SELinux crap by default? :-( )
Comment 36 Kevin Kofler 2011-10-31 17:15:27 EDT
By comment #34, it looks like SELinux is banning the kcm_clock helper from running hwclock. :-(
Comment 37 Fedora Update System 2011-10-31 21:26:15 EDT
Package kdebase-workspace-4.7.2-12.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kdebase-workspace-4.7.2-12.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-15188
then log in and leave karma (feedback).
Comment 38 Fedora Update System 2011-11-01 01:15:26 EDT
kde-settings-4.7-13.fc16.4, kdebase-workspace-4.7.2-14.fc16, kdelibs-4.7.2-5.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 39 Kevin Kofler 2011-11-01 06:55:18 EDT
Reopening, reassigning to selinux-policy, which seems to be in the way of the fix (see comment #34).
Comment 40 Miroslav Grepl 2011-11-01 07:13:41 EDT
But still I don't see any avc msgs?
Comment 41 Kevin Kofler 2011-11-01 07:29:26 EDT
We'll have to wait for Rex Dieter to get up and followup, unless somebody else posts the AVC.
Comment 42 Rex Dieter 2011-11-01 10:29:03 EDT
OK, I see 3 alerts from setroubleshoot every time I adjust time settings via kcm-clock now:

1.

SELinux is preventing /usr/libexec/kde4/kcmdatetimehelper from create access on the unix_dgram_socket Unknown.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that kcmdatetimehelper should be allowed create access on the Unknown unix_dgram_socket 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 kcmdatetimehelp /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:gnomeclock_t:s0-s0:c0.c1023
Target Context                system_u:system_r:gnomeclock_t:s0-s0:c0.c1023
Target Objects                Unknown [ unix_dgram_socket ]
Source                        kcmdatetimehelp
Source Path                   /usr/libexec/kde4/kcmdatetimehelper
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           kdebase-workspace-4.7.2-14.fc16
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-51.fc16
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 3.1.0-5.fc16.x86_64 #1
                              SMP Thu Oct 27 03:46:50 UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    Tue 01 Nov 2011 09:26:47 AM CDT
Last Seen                     Tue 01 Nov 2011 09:26:47 AM CDT
Local ID                      e63261b4-7034-48a0-a44e-8a7039eada15

Raw Audit Messages
type=AVC msg=audit(1320157607.498:103): avc:  denied  { create } for  pid=2111 comm="kcmdatetimehelp" scontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tcontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tclass=unix_dgram_socket


type=SYSCALL msg=audit(1320157607.498:103): arch=x86_64 syscall=socket success=no exit=EACCES a0=1 a1=80002 a2=0 a3=0 items=0 ppid=2110 pid=2111 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=kcmdatetimehelp exe=/usr/libexec/kde4/kcmdatetimehelper subj=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 key=(null)

Hash: kcmdatetimehelp,gnomeclock_t,gnomeclock_t,unix_dgram_socket,create

audit2allow

#============= gnomeclock_t ==============
allow gnomeclock_t self:unix_dgram_socket create;

audit2allow -R

#============= gnomeclock_t ==============
allow gnomeclock_t self:unix_dgram_socket create;



2. 
 SELinux is preventing /usr/libexec/kde4/kcmdatetimehelper from using the dac_override capability.

*****  Plugin dac_override (91.4 confidence) suggests  ***********************

If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system
Then turn on full auditing to get path information about the offending file and generate the error again.
Do

Turn on full auditing
# auditctl -w /etc/shadow -p w
Try to recreate AVC. Then execute
# ausearch -m avc -ts recent
If you see PATH record check ownership/permissions on file, and fix it, 
otherwise report as a bugzilla.

*****  Plugin catchall (9.59 confidence) suggests  ***************************

If you believe that kcmdatetimehelper should have the dac_override capability 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 kcmdatetimehelp /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:gnomeclock_t:s0-s0:c0.c1023
Target Context                system_u:system_r:gnomeclock_t:s0-s0:c0.c1023
Target Objects                Unknown [ capability ]
Source                        kcmdatetimehelp
Source Path                   /usr/libexec/kde4/kcmdatetimehelper
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           kdebase-workspace-4.7.2-14.fc16
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-51.fc16
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 3.1.0-5.fc16.x86_64 #1
                              SMP Thu Oct 27 03:46:50 UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    Tue 01 Nov 2011 09:26:47 AM CDT
Last Seen                     Tue 01 Nov 2011 09:26:47 AM CDT
Local ID                      cf7ebc21-7144-4b6a-9bb6-bfadfdbe0d2c

Raw Audit Messages
type=AVC msg=audit(1320157607.505:104): avc:  denied  { dac_override } for  pid=2111 comm="kcmdatetimehelp" capability=1  scontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tcontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tclass=capability


type=SYSCALL msg=audit(1320157607.505:104): arch=x86_64 syscall=mkdir success=no exit=EACCES a0=171e478 a1=1ff a2=ffffffffffffff70 a3=7fff9bc4ee10 items=0 ppid=1 pid=2111 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=kcmdatetimehelp exe=/usr/libexec/kde4/kcmdatetimehelper subj=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 key=(null)

Hash: kcmdatetimehelp,gnomeclock_t,gnomeclock_t,capability,dac_override

audit2allow

#============= gnomeclock_t ==============
allow gnomeclock_t self:capability dac_override;

audit2allow -R

#============= gnomeclock_t ==============
allow gnomeclock_t self:capability dac_override;



3.
SELinux is preventing /usr/libexec/kde4/kcmdatetimehelper from read access on the file online.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that kcmdatetimehelper should be allowed read access on the online 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 kcmdatetimehelp /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:gnomeclock_t:s0-s0:c0.c1023
Target Context                system_u:object_r:sysfs_t:s0
Target Objects                online [ file ]
Source                        kcmdatetimehelp
Source Path                   /usr/libexec/kde4/kcmdatetimehelper
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           kdebase-workspace-4.7.2-14.fc16
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-51.fc16
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 3.1.0-5.fc16.x86_64 #1
                              SMP Thu Oct 27 03:46:50 UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    Tue 01 Nov 2011 09:27:55 AM CDT
Last Seen                     Tue 01 Nov 2011 09:27:55 AM CDT
Local ID                      193e33b7-3e03-485d-9cd7-34cfac45e4e1

Raw Audit Messages
type=AVC msg=audit(1320157675.10:105): avc:  denied  { read } for  pid=2111 comm="kcmdatetimehelp" name="online" dev=sysfs ino=34 scontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysfs_t:s0 tclass=file


type=SYSCALL msg=audit(1320157675.10:105): arch=x86_64 syscall=open success=no exit=EACCES a0=34b5376fc8 a1=80000 a2=1fffe6f13e4f a3=4011 items=0 ppid=1 pid=2111 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=kcmdatetimehelp exe=/usr/libexec/kde4/kcmdatetimehelper subj=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 key=(null)

Hash: kcmdatetimehelp,gnomeclock_t,sysfs_t,file,read

audit2allow

#============= gnomeclock_t ==============
allow gnomeclock_t sysfs_t:file read;

audit2allow -R

#============= gnomeclock_t ==============
allow gnomeclock_t sysfs_t:file read;
Comment 43 Daniel Walsh 2011-11-01 11:11:47 EDT
Rex can you execute

# auditctl -w /etc/shadow -p w

And then recreate the AVC's.  I want to know why it needs dac_override.  This should provide additional PATH record to show why it needs it.
Comment 44 Daniel Walsh 2011-11-01 11:13:46 EDT
I also wonder if this clock app is getting ready to send a syslog message.
Comment 45 Daniel Walsh 2011-11-01 11:15:02 EDT
Could you execute

nm -D kcmdatetimehelp | grep syslog
Comment 46 Miroslav Grepl 2011-11-21 07:51:06 EST
I think we should have a fix with selinux-policy-3.10.0-58.fc16
Comment 47 Fedora Update System 2011-11-24 08:22:25 EST
selinux-policy-3.10.0-59.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-59.fc16
Comment 48 Carl G. 2011-11-24 18:08:39 EST
Should it be added to the CommonBugs wiki page?
Comment 49 Fedora Update System 2011-11-24 21:17:42 EST
Package selinux-policy-3.10.0-60.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-60.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-16371/selinux-policy-3.10.0-60.fc16
then log in and leave karma (feedback).
Comment 50 Miroslav Grepl 2011-11-28 04:01:29 EST
(In reply to comment #48)
> Should it be added to the CommonBugs wiki page?

Actually I don' think so. I believe we added a proper fix to this update and users should see this no longer.
Comment 51 Kevin Kofler 2011-11-28 13:02:42 EST
Well, it'll still hit live image users…
Comment 52 Fedora Update System 2011-11-29 21:00:23 EST
selinux-policy-3.10.0-61.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.