Thanks for your report. I’m afraid I can't reproduce this (starting with F22 KDE Live image, updating all packages using apper).

Is there anything in the system log from that time? Anything particular about the setup (e.g. other users logged in, using remote access instead of the physical console)?

I'm not so sure this is KDE-specific. I am using GNOME, and I am also getting prompted when I try to suspend my system. This has only changed behaviour in the last week or so, so it does sound like it's related to the polkit 0.113 update.

I am using F21 with polkit-0.113-4.fc21.x86_64 .

My org.freedesktop.login1.suspend action looks correct:

  $ pkaction --action-id org.freedesktop.login1.suspend --verbose
  org.freedesktop.login1.suspend:
    description:       Suspend the system
    message:           Authentication is required for suspending the system.
    vendor:            The systemd Project
    vendor_url:        http://www.freedesktop.org/wiki/Software/systemd
    icon:              
    implicit any:      auth_admin_keep
    implicit inactive: auth_admin_keep
    implicit active:   yes

And I am the only active session:

  $ loginctl list-sessions
     SESSION        UID USER             SEAT            
           1       1000 mchapman         seat0           

  1 sessions listed.
  $ loginctl show-session 1 | grep Active=
  Active=yes

Yet PK thinks I need authentication:

  $ pkcheck --action-id org.freedesktop.login1.suspend --process $$
  polkit\56retains_authorization_after_challenge=1
  Authorization requires authentication and -u wasn't passed.

It really does look like PK isn't detecting that my session is active, so it's using the "implicit inactive" policy instead.

Yes, that part of the code did change in 0.113 (http://cgit.freedesktop.org/polkit/commit/src/polkitbackend/polkitbackendsessionmonitor-systemd.c?id=a68f5dfd7662767b7b9822090b70bc5bd145c50c and http://cgit.freedesktop.org/polkit/commit/src/polkitbackend/polkitbackendsessionmonitor-systemd.c?id=a29653ffa99e0809e15aa34afcd7b2df8593871c ) and broken session detection could explain the symptoms; but those changes were supposed to increase the number of situations considered active, not restrict them.

A possible way to help debug this would be to replace ExecStart= in /usr/lib/systemd/system/polkit.service with
> Environment=G_MESSAGES_DEBUG=all
> ExecStart=/usr/lib/polkit-1/polkitd
and restart polkit (or perhaps a reboot might be required), then use journalctl for the full debug output of the polkit unit. (Note that the debug output may contain private information.)  In particular the debug messages from the latter patch (“Checking whether session %s is active” etc.) might be helpful.

Thanks for the debug tips -- I'll try them if / when the issue reappears.

Strange thing is that after updating a few seemingly unrelated components yesterday, namely

  bash-4.3.39-4.fc22.x86_64  (fixed a memleak)
  plasma-desktop-5.3.2-3.fc22.x86_64
  systemd-219-19.fc22.x86_64

and again updating to polkit.x86_64 0.113-1.fc22 (latest) today, I no longer get the authentication problems right now.

@ Mike C. -- did you update to the latest bash and systemd already?

If the problem does not reappear, I am tempted to downgrade bash,
plasma-desktop and systemd for a test, to narrow down the polkit issue.

(In reply to Miloslav Trmač from comment #1)

> Is there anything in the system log from that time? Anything particular
> about the setup (e.g. other users logged in, using remote access instead of
> the physical console)?

When the authentication issues occurred, I had 3 sessions

# loginctl
   SESSION        UID USER             SEAT            
         1      23629 nfd              seat0           
         3      23629 nfd              seat0           
         2      23629 nfd              seat0

3 sessions listed.

but I was aware of only 2 (login to a console + login to KDE), both of which were local. However, one of those sessions (the console) was not active at the time -- could polkit (when called from KDE) for some reason mix up these sessions?

Unfortunately, I don't have more detailed info (as in comment #2) for the failure case.

Another error in /var/log/Xorg.0.log looks suspicous

  [   106.597] (EE) systemd-logind: failed to get session:
               PID 2104 does not belong to any known session 

but this one occurred today again, and yet polkit seems to be working right now.

(In reply to Miloslav Trmač from comment #3)
> A possible way to help debug this would be to replace ExecStart= in
> /usr/lib/systemd/system/polkit.service with
> > Environment=G_MESSAGES_DEBUG=all
> > ExecStart=/usr/lib/polkit-1/polkitd

I also had to wrap pkla-local-authorization to drop that variable, otherwise its debug messages confused polkitd.

> and restart polkit (or perhaps a reboot might be required),

Stopping it seems sufficient, as it just starts up again when bus-activated.

So here's the log:

"""
system-bus-name::1.348 is inquiring whether unix-process:6490:17083528 is authorized for org.freedesktop.login1.suspend
 user of caller is unix-user:mchapman
 user of subject is unix-user:mchapman

checking whether unix-process:6490:17083528 is authorized for org.freedesktop.login1.suspend
  0x7f99062266c0
Checking whether session 1 is active.
Session 1 has UID 1000.
UID 1000 has state online.
 subject is in session 1 (local=1 active=0)

checking whether unix-process:6490:17083528 is authorized for org.freedesktop.login1.suspend-multiple-sessions
  0x7f98f4003b80
Checking whether session 1 is active.
Session 1 has UID 1000.
UID 1000 has state online.
 subject is in session 1 (local=1 active=0)
 challenge (implicit_authorization = auth_admin_keep)

checking whether unix-process:6490:17083528 is authorized for org.freedesktop.login1.suspend-ignore-inhibit
  0x7f9906265360
Checking whether session 1 is active.
Session 1 has UID 1000.
UID 1000 has state online.
 subject is in session 1 (local=1 active=0)
 challenge (implicit_authorization = auth_admin_keep)

 challenge (implicit_authorization = auth_admin_keep)
"""

FWIW, I too have that Xorg message:

gdm-Xorg-:0[1404]: (EE) systemd-logind: failed to get session: PID 1404 does not belong to any known session

I'm not sure if it's relevant though. That's the PID of my GDM process, and it's true that that particular PID isn't in any logind session. Certainly the PID I used when testing the org.freedesktop.login1.suspend action above is in my active session:

$ systemctl status 6490
● session-1.scope - Session 1 of user mchapman
   Loaded: loaded
  Drop-In: /run/systemd/system/session-1.scope.d
           └─50-After-systemd-logind\x2eservice.conf, 50-After-systemd-user-sessions\x2eservice.conf, 50-Description.conf, 50-SendSIGHUP.conf, 50-Slice.conf
   Active: active (running) since Wed 2015-07-15 10:55:39 AEST; 1 day 23h ago
   CGroup: /user.slice/user-1000.slice/session-1.scope
...
           ├─ 6490 bash
...

(In reply to Michael Chapman from comment #6)
> UID 1000 has state online.

And that looks like the problem there. The polkit code is testing for the string "active", not "online". According to the sd_uid_get_state(3) manpage, "active" should be returned if "user logged  in, and has at least one active session, i.e. one session in the foreground".

So perhaps a systemd bug?

If I had to guess, I'd say the F21 systemd package needs to have this commit backported:

  http://cgit.freedesktop.org/systemd/systemd/commit/?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6

It looks like the patch is already ported to F22 systemd though, and Fredy Neeser appears to be running a version of systemd that includes it. So I'm not sure that it's a total fix for the problems we're seeing here.

Michael, thanks for your excellent investigation.

I just retested on F22 with the latest polkit and a downgraded systemd:

# rpm -q polkit                       
polkit-0.113-1.fc22.x86_64

# rpm -q systemd
systemd-219-13.fc22.x86_64


The test below (switching forth and back b/w a VT and X11) clearly shows the bug in systemd-219-13.fc22.x86_64, which affected authentication in combination with polkit-0.113-1.fc22.x86_64.


Step 1: Boot, switch to VT and login as user 'xyz'
--------------------------------------------------
$ cat /run/systemd/users/23629 
# This is private data. Do not parse.
NAME=xyz
STATE=active
...
SESSIONS=1
SEATS=seat0
ACTIVE_SESSIONS=1
ONLINE_SESSIONS=1
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0

Step 2: Switch back to X11 login screen and login to KDE as user 'xyz'
----------------------------------------------------------------------
$ cat /run/systemd/users/23629 
# This is private data. Do not parse.
NAME=xyz
STATE=online          <== BUG in systemd-219-13.fc22.x86_64 (should be 'active')
...
SESSIONS=2 1
SEATS=seat0 seat0
ACTIVE_SESSIONS=2
ONLINE_SESSIONS=2 1
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0 seat0

Immediately a popup "Authentication is required to refresh the system sources"
appears ... this is the polkit issue we were seeing

Step 3: Switch back to VT
-------------------------
$ cat /run/systemd/users/23629 
# This is private data. Do not parse.
NAME=xyz
STATE=active
...
SESSIONS=2 1
SEATS=seat0 seat0
ACTIVE_SESSIONS=2
ONLINE_SESSIONS=2 1
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0 seat0

This is correct now.

Step 4: Switch back to X11
--------------------------
$ cat /run/systemd/users/23629 
# This is private data. Do not parse.
NAME=xyz
STATE=active
...
SESSIONS=2 1
SEATS=seat0 seat0
ACTIVE_SESSIONS=2      <== BUG in systemd-219-13.fc22.x86_64 (should be '1' now)
ONLINE_SESSIONS=2 1
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0 seat0

Although the file contents are again incorrect, polkit is happy now
because the user is considered active (no more authentication popups).

                            ***

I can confirm that the above systemd/logind bug is now resolved in
systemd-219-19.fc22.x86_64 .

==> There should be a new dependency that
    polkit requires at least systemd-219-19.fc22.x86_64

Here's a summary of the "resolution" by updating systemd:

systemd-219-19.fc22 has a recent commit (2 June 2015) that resolves an issue

  http://cgit.freedesktop.org/systemd/systemd/commit/?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6
  logind: Save the user’s state when a session enters SESSION_ACTIVE
  
  When (for example) switching from X11 to a new VT and logging in there,
  creating a new session, the user state file (/run/systemd/users/$uid)
  is not updated after the session becomes active. The latest time it is
  saved is when the session is in SESSION_OPENING.
  This results in a /run/systemd/users/$uid file which contains
  STATE=online for the current user on the current active VT,
  which is obviously wrong.
  As functions like sd_uid_get_state() use this file to get the user’s state,
  this could result in things like PolicyKit making incorrect decisions
  about the user’s state.
  (See https://bugs.freedesktop.org/show_bug.cgi?id=76358.)
  Fix this by re-saving the state for a session’s user after completing the
  state_job for that session.
  https://bugs.freedesktop.org/show_bug.cgi?id=90818
  
which affects a recent design change in PolicyKit described here
  https://bugs.freedesktop.org/show_bug.cgi?id=76358
  Bug 76358 - Please use sd_uid_get_state() to make security decisions, not sd_pid_get_session() 
  
and here
  http://cgit.freedesktop.org/polkit/commit/?id=a29653ffa99e0809e15aa34afcd7b2df8593871c
  sessionmonitor-systemd: Use sd_uid_get_state() to check session activity
  
The bug resolved by the systemd commit is explained here in more detail:
  https://bugs.freedesktop.org/show_bug.cgi?id=90818  
  Bug 90818 - logind: Save the user’s state when a session enters SESSION_ACTIVE

                       ***
  
My interpretation of the above systemd commit:
Apparently logind did not correctly update the user state file
(/run/systemd/users/$uid) while creating a new Virtual Terminal (VT).

logind did update the user state file when the session was opening, which caused /run/systemd/users/$uid file to contain STATE=online
for the current user.
  
The bug was that this (temporary) STATE change for the current user persisted
even after the VT became active, and even after switching back *for the first time* from the new VT to X11.

See also:
  https://github.com/systemd/systemd/commits/master/src/login/logind-dbus.c
which shows the commit
  https://github.com/systemd/systemd/commit/41dfeaa194c18de49706b5cecf4e53accd12b7f6
  logind: Save the user’s state when a session enters SESSION_ACTIVE
  
on 2 June 2015.


To resolve the present bug and prevent users from running the latest polkit with an old systemd, I propose to add a dependency that polkit requires at least systemd-219-19.fc22.x86_64 .

Great work, thanks for the investigation.

So, to be explicit, steps to reproduce are in comment #9. They manifest either on F22 with polkit 0.113-any and systemd <13, or on F21 with https://admin.fedoraproject.org/updates/polkit-0.113-4.fc21 (make sure to install polkit-libs if using manually downloaded RPMs instead of the repo; and reboot or manually restart polkitd to have this take effect) and systemd-216-25.fc21.x86_64

A workaround seems to be to switch to the other session and back?

Adding a dependency for F22 can certainly be done; we still need to have the fix backported in F21 though.

So, reassigning to systemd to 1) confirm the diagnosis and 2) fix this in F21; then I can add the dependencies on new enough systemd to both F21 and F22 at once.

And so falls Yet Another bug into the abyss that is systemd-maint.

I'm CCed on six bugs assigned to systemd-maint, and not a single one of them seems to be going anywhere. A little progress update every now and then would be nice. Please? :-)

polkit-0.113 and systemd-227 reproduce the same issue, and workaround (but unsafe) rules (remove subject.active) for example:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.timedate1.set-ntp" &&
        subject.isInGroup("wheel")) {
        return polkit.Result.YES;
    }
});

PS: here comes ntp CVE: CVE-2015-7871, CVE-2015-7849, CVE-2015-7852, CVE-2015-7853, CVE-2015-7854, CVE-2015-7848, CVE-2015-7850, CVE-2015-7851

Regards,
Leslie Zhai

No, I don't think any security vulnerabilities are introduced by this bug -- certainly not any of those CVEs, which have nothing to do with this issue!.

This bug mistakenly treats "active" users as if they were "inactive". Fedora does not ship any polkit policies which grant more actions to inactive users than to active users, so this bug does not allow a user to perform an action they should not be able to.

In the experiment of Comment 9, I must have mis-annotated some of the entries of the /run/systemd/users/23629 file.  For the records, here's a version with corrected annotations:


Step 1: Boot, switch to VT and login as user 'xyz'
--------------------------------------------------
$ cat /run/systemd/users/23629 
# This is private data. Do not parse.
NAME=xyz
STATE=active
...
SESSIONS=1
SEATS=seat0
ACTIVE_SESSIONS=1
ONLINE_SESSIONS=1
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0

Step 2: Switch back to X11 login screen and login to KDE as user 'xyz'
----------------------------------------------------------------------
$ cat /run/systemd/users/23629 
# This is private data. Do not parse.
NAME=xyz
STATE=online  # <== BUG in systemd-219-13.fc22.x86_64 (should be 'active')
...
SESSIONS=2 1
SEATS=seat0 seat0
ACTIVE_SESSIONS=2
ONLINE_SESSIONS=2 1
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0 seat0

Immediately a popup "Authentication is required to refresh the system sources"
appears ... this is the polkit issue we were seeing

Step 3: Switch back to VT
-------------------------
$ cat /run/systemd/users/23629 
# This is private data. Do not parse.
NAME=xyz
STATE=active
...
SESSIONS=2 1
SEATS=seat0 seat0
ACTIVE_SESSIONS=2  # <== BUG in systemd-219-13.fc22.x86_64 (should be '1' now)
ONLINE_SESSIONS=2 1
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0 seat0

This is correct now.

Step 4: Switch back to X11
--------------------------
$ cat /run/systemd/users/23629 
# This is private data. Do not parse.
NAME=xyz
STATE=active
...
SESSIONS=2 1
SEATS=seat0 seat0
ACTIVE_SESSIONS=2
ONLINE_SESSIONS=2 1
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0 seat0

Polkit is happy now because the user is considered active
(STATE=active ==> no more authentication popups).

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. 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 EOL if it remains open with a Fedora  'version'
of '21'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 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 this bug is closed as described in the policy above.

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.

Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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.