Bugzilla – Bug 954139
polkit 0.113-6.1 creates unnecessary password prompt on login
Last modified: 2018-04-26 12:10:06 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0 Build Identifier: a couple of days ago there was a polkit update to 0.113-6.1 in the Leap 42.1 update repo. Since then - when I logout and then log back in I am presented with a password prompt. if I enter the root password the updater application then tells me no connection due to unauthorised access (or something similar) and if I enter no password then I get the same message. In addition - using the kde menu entries to either reboot or shutdown no longer work - they simply just log me out. rolling back polkit to 0.112-4.2 solves the issue. Reproducible: Always
Created attachment 655073 [details] password prompt on login presented with password prompt after logging out of KDE and then back in
I can confirm this. On logout, followed by login, I am prompted for authentication and need to give the root password. After the root password is accepted, I am prompted for the kdewallet password (for NetworkManager), so the two appear to be related.
I have an additional problem, since that polkit update to 0.113-6.1. I use "lightdm" as login manager. On booting, I can access the "lightdm" menu to reboot or shutdown the system. But, after login followed by a logout, I can no longer access that menu. If I want to shutdown after logout, I have to use CTRL-ALT-F1, login as root, and shutdown at the command line. Reverting to polkit 0.112-4.2 fixes this problem. This may be unrelated, and I can start as a separate bug report if you prefer. But I think it is the same underlying issue. It looks as if there is a breakdown of communication between polkit and the systemd user process.
this logout problem pattern seems common. not sure if the network manager issue is related, but probably also caused by polkit update
*** Bug 955242 has been marked as a duplicate of this bug. ***
Created attachment 656196 [details] polkit-0.113-9.1.x86_64.rpm i reverted a patch that probably is causing this. home:msmeissn:branches:openSUSE:Leap:42.1:Update/polkit.openSUSE_Leap_42.1_Update can you try the attached rpm (or from above obs project)
so far so good. With the updated polkit I am no longer prompted for password on logout/login and the system updater no longer spews out three messages about being unable to connect.
ok, so this change seems buggy ... although I do not see it. can you, when such a case would have happened run: loginctl cat /run/systemd/users/`id -u` and paste/attach it here?
oh, sorry. Perhaps I wasn't clear in my post. The rpm you provided has solved the issue for me and I no longer see the problem that I reported initially. . . . or do you mean you would like me to revert to polkit 0.113-6.1 and then post the output next time I see the issue?
ok . . . so here is the output with pasword prompt displayed after login using polkit 0.113-6.1 farcus@linux-qyyw:~> loginctl SESSION UID USER SEAT 2 1000 farcus seat0 4 1000 farcus seat0 9 1000 farcus seat0 13 1000 farcus seat0 14 484 sddm seat0 15 1000 farcus seat0 6 sessions listed. farcus@linux-qyyw:~> cat /run/systemd/users/`id -u` # This is private data. Do not parse. NAME=farcus STATE=online RUNTIME=/run/user/1000 SERVICE=user@1000.service SLICE=user-1000.slice DISPLAY=15 REALTIME=1447770405634912 MONOTONIC=39635637 SESSIONS=15 13 9 4 2 SEATS=seat0 seat0 seat0 seat0 seat0 ACTIVE_SESSIONS=15 ONLINE_SESSIONS=15 ACTIVE_SEATS=seat0 ONLINE_SEATS=seat0
STATE=online is the culprit. It would expected STATE=active to be a "better" state. how are you logged in in those sessions? is there one via ssh or all via console?
no ssh logins here Simply logged in via kdm (or whatever it's replacement is in plasma 5 - sddm, I think)
can you run: loginctl user-status farcus|grep State loginctl user-status sddm|grep State
farcus@linux-qyyw:~> loginctl user-status farcus|grep State State: active │ └─15810 grep --color=auto State farcus@linux-qyyw:~> loginctl user-status sddm|grep State State: closing
I am an openSUSE LEAP 42.1 user This bug had been blocking my user control of Network Manager resources. I downloaded and installed the polkit-0.113-9.1x86_64.rpm and installed it, ignoring a YAST dependency warning that libpolkit0 = 0.113-9.1 was required. So far, this fix seems to work and resolve the Net Manager issues I had.
The rpm provided in Comment 6 has resolved my update issues.
I really wonder why systemd puts STATE=online in the state file while it only some lines later lists ACTIVE_SESSIONS=15 ONLINE_SESSIONS=15 ACTIVE_SEATS=seat0 ONLINE_SEATS=seat0 it should report STATE=active I looked over the logic in src/login/logind-user.c . user_get_state has a bit different logic, but it should still report USER_ACTIVE :/
(In reply to Marcus Meissner from comment #17) Check the clocks! Beside this on the local (virtual) console or a local X session the STATE is active whereas it is not via ssh/slogin: /suse/werner> grep STATE /run/systemd/users/`id -u` STATE=active logout ... slogin <test> <test> /suse/werner> grep STATE /run/systemd/users/`id -u` STATE=online
facrcus above has a local session, no ssh logins. I have the vague feeling its related to sddm somehow, or some other race condition
I am still logged in from yesterday in this "online" status, but if I then login in a seperate konsole to the localhost using ssh, this changes to "active", and then it also stays active. user@PC:~> grep STATE /run/systemd/users/`id -u` STATE=online user@PC:~> ssh user@localhost Password: Have a lot of fun... user@PC:~> grep STATE /run/systemd/users/`id -u` STATE=active and, indeed, in this active state I see no problem with the updater. If I then go back and manually edit /run/systemd/users/1000 to contain the line STATE=online (or anthing other than "active") it breaks things again.
if you then logout and relogin to the desktop (via sddm/kdm), what is the state afterwards?
not sure if this is helpful . . . boot computer > login to plasma 5 via sddm farcus@linux-qyyw:~> grep STATE /run/systemd/users/`id -u` STATE=active Logout (kde menu shortcut) back to sddm > log back in as same user (as prev) farcus@linux-qyyw:~> grep STATE /run/systemd/users/`id -u` STATE=online
thats why i still have sddm or systemd in my eyes for cause of this problem
(In reply to Marcus Meissner from comment #24) > thats why i still have sddm or systemd in my eyes for cause of this problem The problem occurs on 13.2 with kdm too. See bug#950864 (doesn't mention kdm, but I can reproduce it with kdm here). So it's unlikely that sddm is causing this...
In response to Comment 21: Clean reboot, login: state = active Logout, Login state = online Login via ssh on terminal state = active Logout, Login state = online. Tested for both ssdm and kdm as display manager. In any case I think this is the commit that introduced the problem http://cgit.freedesktop.org/polkit/commit/?id=a29653ffa99e0809e15aa34afcd7b2df8593871c but I think it's a problem with systemd, and they have identified it as such a few months ago. See this for more information: https://github.com/systemd/systemd/pull/58
Ok, it gets a bit more silly now. Since I couldn't get debugging working I ran an strace on: strace /usr/lib/polkit-1/polkitd -r to see what's going on. First it reads /run/systemd/users/1000 and if it finds STATE=online it fails, if it finds STATE=active then good. If it doesn't find anything STATE= (empty) then it reads the file /run/systemd/sessions/11 (or whatever is your session file) and there is also an STATE variable, but this can be blablabla for all it cares, it only reads the value of ACTIVE is read. Only if it is exactly 0 then it will fail the polkit check. So: ACTIVE=1 -> SUCCES ACTIVE=2 -> SUCCES ACTIVE=-1000 -> SUCCES ACTIVE=0 -> FAIL ACTIVE=blablabla -> SUCCES I can consistently break the polkit check by changing active to 0 (if in /run/systemd/users/1000 state=<blank>) and fix it by putting anything else there.
systemd src/login/sd-loginc.c: _public_ int sd_session_is_active(const char *session) { r = parse_env_file(p, NEWLINE, "ACTIVE", &s, NULL); r = parse_boolean(s); explains this ;) But I see the systemd issue from your comment #c26.
Any timeframe on the fix of this bug? I believe a lot of users are hitting this bug. Bo
i have just released the revert of the polkit user/session change. but the actual bug in systemd will also get fixed I hope.
openSUSE-RU-2015:2079-1: An update that has one recommended fix can now be installed. Category: recommended (low) Bug References: 954139 CVE References: Sources used: openSUSE Leap 42.1 (src): polkit-0.113-9.1 openSUSE 13.2 (src): polkit-0.113-3.11.1 openSUSE 13.1 (src): polkit-0.113-12.1
With the lastest polkit update, the problem with "lightdm" that I mentioned in comment #3 is now fixed.
released update. systemd bug is also open
This is an autogenerated message for OBS integration: This bug (954139) was mentioned in https://build.opensuse.org/request/show/346398 Factory / polkit
This is an autogenerated message for OBS integration: This bug (954139) was mentioned in https://build.opensuse.org/request/show/346801 Factory / polkit
SUSE-RU-2016:0240-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 954139 CVE References: Sources used: SUSE Linux Enterprise Workstation Extension 12-SP1 (src): polkit-0.113-5.6.1 SUSE Linux Enterprise Workstation Extension 12 (src): polkit-0.113-5.6.1 SUSE Linux Enterprise Software Development Kit 12-SP1 (src): polkit-0.113-5.6.1 SUSE Linux Enterprise Software Development Kit 12 (src): polkit-0.113-5.6.1 SUSE Linux Enterprise Server 12-SP1 (src): polkit-0.113-5.6.1 SUSE Linux Enterprise Server 12 (src): polkit-0.113-5.6.1 SUSE Linux Enterprise Desktop 12-SP1 (src): polkit-0.113-5.6.1 SUSE Linux Enterprise Desktop 12 (src): polkit-0.113-5.6.1
This is an autogenerated message for OBS integration: This bug (954139) was mentioned in https://build.opensuse.org/request/show/595145 Factory / polkit