Bug 749516

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.

Confirming the issue, tested on KDE 4.7.2 (Fedora 16 Final TC2).

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...

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

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

CC for blocker votes.

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"?

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.)

(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?

(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?

(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.

`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.

(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.

Setting the time using 'date' in F16 and using 'reboot -f' to bypass init system doesn't fix the problem, time is not persisted.

(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.

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.

'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.

Is it possible to enable sync-hwclock on the KDE spin?

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.

To fix this, looks like calling "hwclock --systohc" after the settimeofday call is enough. I'm writing a patch.

Patch here: https://git.reviewboard.kde.org/r/102985/

Rawhide build: http://koji.fedoraproject.org/koji/buildinfo?buildID=271355

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

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).

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).

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.

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.

I proposed some changes in coreutils (mainly man page adjustments) in bug 750244.

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!

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.

(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

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

(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.

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

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.

It might need a matching selinux-policy update. I need the AVCs.

(Grrr, now why are we enabling this SELinux crap by default? :-( )

By comment #34, it looks like SELinux is banning the kcm_clock helper from running hwclock. :-(

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).

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.

Reopening, reassigning to selinux-policy, which seems to be in the way of the fix (see comment #34).

But still I don't see any avc msgs?

We'll have to wait for Rex Dieter to get up and followup, unless somebody else posts the AVC.

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;

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.

I also wonder if this clock app is getting ready to send a syslog message.

Could you execute

nm -D kcmdatetimehelp | grep syslog

I think we should have a fix with selinux-policy-3.10.0-58.fc16

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

Should it be added to the CommonBugs wiki page?

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).

(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.

Well, it'll still hit live image users…

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.