= Summary = When changing the system time using the gnome clock applet, policykit does not always remember the cached credentials because the system time has changed and the credentials may have expired. According to davidz, entering the root password should be remembered for about 5 minutes. > 10:20 davidz: $ pkaction --verbose --action-id org.gnome.clockapplet.mechanism.settime > 10:20 davidz: org.gnome.clockapplet.mechanism.settime: > 10:20 davidz: description: Change system time > 10:20 davidz: message: Privileges are required to change the system time. > 10:20 davidz: vendor: The GNOME Project > 10:20 davidz: vendor_url: http://www.gnome.org/ > 10:20 davidz: icon: gnome-panel-clock > 10:20 davidz: implicit any: no > 10:20 davidz: implicit inactive: no > 10:21 davidz: implicit active: auth_admin_keep > 10:21 davidz: this suggests that you should be able to keep authorization for a little while > 10:21 davidz: typically five minutes = Versions tested = * polkit-0.96-1.fc13 * gnome-panel-2.30.0-4.fc13 = Steps to reproduce = 1. Right-client clock applet 2. Select 'Time Settings' 3. Adjust time and select 'Set System Time...' 4. Enter root password as prompted by polkit 5. Repeat process multiple times, setting the clock both forward and backward. = Additional information = > 10:28 davidz: guint64 time_granted; > 10:28 davidz: guint64 time_expires; > 10:28 davidz: seconds since the epoch > 10:28 davidz: in fact > 10:28 davidz: http://hal.freedesktop.org/docs/polkit/PolkitTemporaryAuthorization.html > 10:29 davidz: this is expressed in public API > 10:29 davidz: so there's no easy way to fix this > 10:29 davidz: now, there's no security bug here - the user can only lose authorization, never gain anything > 10:29 davidz: it's just, granted, annoying > 10:30 davidz: we probably could fix it so it works as expected - the problem is that time_expires is encoded in public API > 10:31 davidz: I guess we fix the daemon side to also store ticks_since_startup > 10:31 davidz: which is a monotone clock sorta > 10:31 davidz: then use that to expire > 10:32 davidz: daemon could even adjust time_obtained and time_expires accordingly > 10:32 davidz: so the UI will present something meaningful
OK, finally got around to fixing this. It actually magically fixes itself if you just update to GLib 2.28 ... this is because g_timeout_add() in 2.28 and later is using monotonic time.. as it should have always done. The rest of the fix is to record the obtained and expired time in monotonic time and only convert it to secs-since-Epoch when returning it. And of course adding doc comments that the returned values will change if system time changes: http://cgit.freedesktop.org/PolicyKit/commit/?id=f646c32853e775d87aa7147f3ad32e70a627bfce One way to verify this fix is by running $ watch pkcheck --list-temp in a terminal (--list-temp is a new option in .101 - I added that explicitly so it's easy to check the fix), then acquire an authorization ('pkexec pk-example-frobnicate' works), then change the time (running date(1) as root works).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.