| Summary: | MCC won't start after logging out/in to KDE session - session recognised by polkit as "online" vs. "active" | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | John L. ten Wolde <johnltw> |
| Component: | RPM Packages | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | Normal | CC: | davidwhodgins, doktor5000, fri, hc, henk, johnltw, lmenut, mageia, mageia, michel.autem, sysadmin-bugs, wilcal.int, xuoy |
| Version: | 5 | Keywords: | validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.freedesktop.org/show_bug.cgi?id=90818 https://bugs.mageia.org/show_bug.cgi?id=16319 |
||
| Whiteboard: | MGA5-64-OK advisory | ||
| Source RPM: | systemd-217-11.mga5 | CVE: | |
| Status comment: | |||
|
Description
John L. ten Wolde
2015-07-17 04:15:48 CEST
@Colin Guthrie Apologies if I appear presumptuous, but I'm adding you to the CC list because you seemed to have had ever so much fun working through those apparently similar (and possibly related) bugs I mentioned in Comment 1. Thank you for your attention. CC:
(none) =>
johnltw, mageia Duplicate of https://bugs.mageia.org/show_bug.cgi?id=13051 ? I am getting this too. Suspend/resume seem to trig this too. CC:
(none) =>
fri (In reply to Morgan Leijström from comment #2) > Duplicate of https://bugs.mageia.org/show_bug.cgi?id=13051 ? > I don't think so. IMHO, this is another issue. @all, when authentication fails, could you report the output of cat /run/systemd/users/$(id -u) CC:
(none) =>
lmenut same problem with MATE. Also clicking on the mageia online applet doesn't work. $ cat /run/systemd/users/$(id -u) # This is private data. Do not parse. NAME=henk STATE=online RUNTIME=/run/user/500 SERVICE=user@500.service SLICE=user-500.slice DISPLAY=c4 REALTIME=1440774533171447 MONOTONIC=186129244 SESSIONS=c4 c3 SEATS=seat0 seat0 ACTIVE_SESSIONS=c4 ONLINE_SESSIONS=c4 ACTIVE_SEATS=seat0 ONLINE_SEATS=seat0 CC:
(none) =>
henk @Henk: have you set the applet to require root login? ----- Today it was not until the third KDE logout/login it failed, i get corresponding output as Henk. "Thankfully", as mageia servers was offline a while, i could not report it immediately, and now some hours later *in same login*, in the same terminal i issue drakconf again just in case - and now it works!! bash-4.3$ cat /run/systemd/users/$(id -u) # This is private data. Do not parse. NAME=morgan STATE=active RUNTIME=/run/user/10702 SERVICE=user@10702.service SLICE=user-10702.slice DISPLAY=c8 REALTIME=1439542090070297 MONOTONIC=23200603 SESSIONS=c8 c1 SEATS=seat0 seat0 ACTIVE_SESSIONS=c8 ONLINE_SESSIONS=c8 ACTIVE_SEATS=seat0 ONLINE_SEATS=seat0 NOTE when OK the line STATE is =active (when not working it is =online) I took me several logout/logins and 2 or 3 reboots, but now it's working again. And the state is "active" now. I also lost my sound, but that's back too. @Morgan: No, the applet just asks for my own password. I think that the problem started today when I logged in with an USB-stick inserted. It did not come on until I took it out and inserted it again. Soon after that I found out that things were not working properly. I've got the same findings as Morgan: when it works STATE=active; when it fails STATE=online. I was just looking into what this STATE business was all about and found this on the sd_uid_get_state (3) manpage: "online" (user logged in, but not active, i.e. has no session in the foreground), "active" (user logged in, and has at least one active session, i.e. one session in the foreground), Well that certainly makes our results of "online" sound wrong. Thanks for feedback. yep, the wrong STATE is the issue. Since polkit 0.113, polkit uses sd_session_is_active() to check session activity, as requested by systemd's devs. http://lists.freedesktop.org/archives/polkit-devel/2015-July/000432.html polkit-0.113 released ... Changes since polkit 0.112: ... Philip Withnall (1): sessionmonitor-systemd: Use sd_uid_get_state() to check session activity https://bugs.freedesktop.org/show_bug.cgi?id=76358 http://cgit.freedesktop.org/polkit/commit/?id=a29653ffa99e0809e15aa34afcd7b2df8593871c With our systemd (217-11.mga5) this state is sometimes wrong with STATE=online instead of STATE=active. This is fixed upstream in systemd v221 by logind: Save the userâs state when a session enters SESSION_ACTIVE http://cgit.freedesktop.org/systemd/systemd/commit/?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6 https://bugs.freedesktop.org/show_bug.cgi?id=90818 see also a full analyse of this bug in Fedora bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1243319 we should backport http://cgit.freedesktop.org/systemd/systemd/commit/?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6 in mga5 systemd in order to fix this issue. See Also:
(none) =>
https://bugs.freedesktop.org/show_bug.cgi?id=90818 I have almost the same on 1 laptop with Mageia 5 kde. Can't run mcc from the icon and get no dialog/gui when I hit Leave -> Shut down If I run drakconf from konsole as user i get this: $ drakconf ==== AUTHENTICATING FOR org.mageia.drakconf.pkexec.run === Authentication is required to run Mageia Control Center GUI Authenticating as: root Password: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie ==== AUTHENTICATION FAILED === Error executing command as another user: Not authorized This incident has been reported. State is active: $ cat /run/systemd/users/$(id -u) # This is private data. Do not parse. NAME=x STATE=active RUNTIME=/run/user/500 SERVICE=user@500.service SLICE=user-500.slice DISPLAY=c1 REALTIME=1442390231969012 MONOTONIC=67279257 SESSIONS=c1 SEATS=seat0 ACTIVE_SESSIONS=c1 ONLINE_SESSIONS=c1 ACTIVE_SEATS=seat0 ONLINE_SEATS=seat0 CC:
(none) =>
hc Forgot to write that this is without any logouts/ins. This happens after boot when I try to run mcc from the icon or Leave -> Shut down
Samuel Verschelde
2015-09-16 14:53:31 CEST
See Also:
(none) =>
https://bugs.mageia.org/show_bug.cgi?id=16319 (In reply to Luc Menut from comment #9) > Thanks for feedback. > yep, the wrong STATE is the issue. > > Since polkit 0.113, polkit uses sd_session_is_active() to check session > activity, as requested by systemd's devs. > http://lists.freedesktop.org/archives/polkit-devel/2015-July/000432.html > polkit-0.113 released > ... > With our systemd (217-11.mga5) this state is sometimes wrong with > STATE=online instead of STATE=active. > > This is fixed upstream in systemd v221 by > logind: Save the userâs state when a session enters SESSION_ACTIVE > http://cgit.freedesktop.org/systemd/systemd/commit/ > ?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6 > https://bugs.freedesktop.org/show_bug.cgi?id=90818 > ... > we should backport > http://cgit.freedesktop.org/systemd/systemd/commit/ > ?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6 > in mga5 systemd in order to fix this issue. Luc, thanks for the thorough analysis. I'll do a test build and report back, as we have an easily reproducible test case for the issue reported in comment 0 Now we still need to figure out what's wrong for all the people that still have polkit issues in general (not caused by the polkit service not being restarted during the mga5 polkit update https://bugs.mageia.org/show_bug.cgi?id=16135 ) E.g. for Henrik above where polkit fails after a fresh boot. And dozens more people reported similar stuff in forums, reasons yet unknown. polkit service and polkit agents seem to be running fine. Priority:
Normal =>
High (In reply to John ten Wolde from comment #0) I get the same kind of problem/bug in GNOME rather regularly but I am totally unable to reproduce it and to characterize the trigger event : after leaving the last session without any apparent trouble and opening a new session, I'm unable to launch MCC. I can do it in my session from a terminal, or connecting in an other session (as "root" or an other User ID) but it does not work in the GNOME GUI. A serial of other troubles are concomitant, like loosing the sound in Banshee or blocking PulseAudio Volume Control. Disconnecting/reconnecting the session does nothing, nor rebooting the system. The problem has something to see with iBus cache corruption because it appears completely solved by manually deleting the /home/<MyId>/.cache/ibus/bus/registry file (or the whole directory) and then restarting the session. CC:
(none) =>
michel.autem Ok, got this also after having issues on starting display manager automatically on boot. Weird thing is, pkexec direct call works just fine, but calling our drakxtools fails (weird as they also essentially call pkexec). [doktor5000@Mageia5]â[15:20:49]â[~] mgaapplet-config Error executing command as another user: Not authorized This incident has been reported. [â]â[doktor5000@Mageia5]â[15:21:09]â[~] pkexec whoami root [doktor5000@Mageia5]â[15:23:06]â[~] cat /run/systemd/users/$(id -u) # This is private data. Do not parse. NAME=doktor5000 STATE=online RUNTIME=/run/user/1000 SERVICE=user@1000.service SLICE=user-1000.slice DISPLAY=c9 REALTIME=1443903417013958 MONOTONIC=40092786 SESSIONS=c9 c1 SEATS=seat0 seat0 ACTIVE_SESSIONS=c9 ONLINE_SESSIONS=c9 c1 ACTIVE_SEATS=seat0 ONLINE_SEATS=seat0 seat0 Reason here is clearly what Luc mentioned, session is considered "online" rather then "active". I've added http://cgit.freedesktop.org/systemd/systemd/commit/?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6 to a local systemd version, and will test. Probably a sane idea to push this to updates_testing for others to test. So please try with systemd-217-11.1.mga5 if your issues still persist. If they do, please at the very least provide a short but clear description how you start your X session, and provide the output of cat /run/systemd/users/$(id -u) ps -ef|grep -v grep|grep polkit systemctl status polkit.service -a Status:
NEW =>
ASSIGNED (In reply to Henrik Christiansen from comment #10) > I have almost the same on 1 laptop with Mageia 5 kde. Yep, almost the same. Please first create a thread in our forums https://forums.mageia.org/en so I can take a closer look. Your issue looks pretty different as your session is active, not online. And you get a different error message: > polkit-agent-helper-1: error response to PolicyKit daemon: > GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie @Bugsquad: For reference, I tried to summarize the current 2 polkit issues we have in this forum post: https://forums.mageia.org/en/viewtopic.php?p=59728#p59728 If you see more polkit issues, please ping me on IRC or so. (In reply to Florian Hubold from comment #16) > @Bugsquad: For reference, I tried to summarize the current 2 polkit issues > we have in this forum post: > https://forums.mageia.org/en/viewtopic.php?p=59728#p59728 > If you see more polkit issues, please ping me on IRC or so. Ok, noted. I was able to reproduce the issue this morning by logging out and back into KDE. I practically never logout, only shutdown, that's why I hadn't had the issue before trying to actually reproduce it. I installed the systemd update candidate, and now after through logout and login back into KDE, I have no issue: the session state is "active" as expected, and I can start e.g. MCC from the launcher. So MGA5-64-OK. Whiteboard:
(none) =>
MGA5-64-OK (In reply to Rémi Verschelde from comment #18) > So MGA5-64-OK. Shall I assign this to QA then? I'd at least like to get some feedback from Colin before we validate this. I mean, this is only a one-line patch that is applied for the fix, but maybe Colin has some more systemd patches that should be applied. Are there more bugs open against systemd for mga5 currently? Assigning to QA team for testing, if the advisory is OK/understandable I'd like to upload that to SVN. Sadly I have no clear steps to reproduce, the following has to suffice: 1. verify the state of your user session is active via "grep -i state /run/systemd/users/$(id -u)" 2. verify that you can run commands via polkit as normal user, e.g. "pkexec whoami" or "drakconf" should work after providing the password to the polkit agent dialog 3. logout from your desktop session, and login again - if the check from 1. now returns the state as online then the commands from 2. should fail 4. after installing the update the issue from 3. should be fixed, the session of the current user should always be state=active. See comment 14 for the first validation example. Suggested advisory: ======================== Since polkit 0.113, polkit uses sd_session_is_active() to check session activity, as requested by systemd's developers: https://bugs.freedesktop.org/show_bug.cgi?id=76358 http://lists.freedesktop.org/archives/polkit-devel/2015-July/000432.html http://cgit.freedesktop.org/polkit/commit/?id=a29653ffa99e0809e15aa34afcd7b2df8593871c With our previous systemd version 217 this state is sometimes wrong with STATE=online instead of STATE=active. This happens either after a user logs out, and logs back in again to his X session, or in some cases when the display manager / X session is manually started from a terminal In each case, it results in polkit not being able to start any program with root authorisation, and there is no workaround for this. An explanation of the two states from sd_uid_get_state (3) manpage: "online" (user logged in, but not active, i.e. has no session in the foreground) "active" (user logged in, and has at least one active session, i.e. one session in the foreground) This has been fixed by backporting a patch from systemd 221 to logind: logind: Save the userâs state when a session enters SESSION_ACTIVE http://cgit.freedesktop.org/systemd/systemd/commit/?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6 References: https://bugs.freedesktop.org/show_bug.cgi?id=90818 https://bugzilla.redhat.com/show_bug.cgi?id=1243319 ======================== Updated packages in core/updates_testing: ======================== i586 libgudev1.0_0-217-11.1.mga5.i586 libgudev1.0-devel-217-11.1.mga5.i586 libgudev-gir1.0-217-11.1.mga5.i586 libsystemd0-217-11.1.mga5.i586 libudev1-217-11.1.mga5.i586 libudev-devel-217-11.1.mga5.i586 nss-myhostname-217-11.1.mga5.i586 python-systemd-217-11.1.mga5.i586 systemd-217-11.1.mga5.i586 systemd-devel-217-11.1.mga5.i586 systemd-units-217-11.1.mga5.i586 x86_64 lib64gudev1.0_0-217-11.1.mga5.x86_64 lib64gudev1.0-devel-217-11.1.mga5.x86_64 lib64gudev-gir1.0-217-11.1.mga5.x86_64 lib64systemd0-217-11.1.mga5.x86_64 lib64udev1-217-11.1.mga5.x86_64 lib64udev-devel-217-11.1.mga5.x86_64 nss-myhostname-217-11.1.mga5.x86_64 python-systemd-217-11.1.mga5.x86_64 systemd-217-11.1.mga5.x86_64 systemd-devel-217-11.1.mga5.x86_64 systemd-units-217-11.1.mga5.x86_64 Source RPMs: systemd-217-11.1.mga5.src.rpm Assignee:
doktor5000 =>
qa-bugs Thanks for this Florian!
William Kenney
2015-10-08 18:46:38 CEST
CC:
(none) =>
wilcal.int
Dave Hodgins
2015-10-09 00:49:06 CEST
CC:
(none) =>
davidwhodgins
Dave Hodgins
2015-10-09 01:10:24 CEST
Keywords:
(none) =>
validated_update An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2015-0145.html Status:
ASSIGNED =>
RESOLVED Hi, This bug is still available for me on at least 2 laptops. I am running mageia5 x86_64 on the first one, mageia5 i686 on the second one. It does not depend on the fact that I log in or out from a previous session. This behaviour occurs since several months but I was leaving with it (see (in french) https://www.mageialinux-online.org/forum/topic-20672+drakconf-mcc-ne-se-lance-pas-a-partir-de-son-icone-sous-xfce.php). As I've installed Mageia on another laptop, and see this bug was still there, I'd like to re-open this bug. After the first login (after reboot), I can't run mcc from the desktop icon nor as user xuo : /home/xuo 16 # mcc ==== AUTHENTICATING FOR org.mageia.drakconf.pkexec.run === Authentication is required to run Mageia Control Center GUI Authenticating as: root Password: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie ==== AUTHENTICATION FAILED === Error executing command as another user: Not authorized This incident has been reported. cat /run/systemd/users/500 # This is private data. Do not parse. NAME=xuo STATE=active RUNTIME=/run/user/500 SERVICE=user@500.service SLICE=user-500.slice DISPLAY=c2 REALTIME=1483992687380753 MONOTONIC=89383081 SESSIONS=c2 SEATS=seat0 ACTIVE_SESSIONS=c2 ONLINE_SESSIONS=c2 ACTIVE_SEATS=seat0 ONLINE_SEATS=seat0 Any idea ? Regards. Xuo. Priority:
High =>
Normal
Nicolas Lécureuil
2017-01-09 21:59:42 CET
Keywords:
validated_update =>
(none) Thanks for the report, but please open an new issue that would reference this one. This bug report was used by the QA team to validate an update, and this cannot be reverted, so it should stayed as RESOLVED FIXED. Keywords:
(none) =>
validated_update I would like to re-open this ticket, which was *never* resolved *at all*, at least for five years and three versions of Mageia : I get still exactly the same symptoms as Xuo in Mageia 7.1 ! This bug occurs *only* when I'm connected under my logId. Everything works fine in any other account, "root" but also any *new* account I create. But suppressing *my* account and re-creating it (keeping /home ..) has no effect : impossible to launch the MCC, and any appli needing "root" privileges. ---------------------------------------------------------------- [michel@localhost ~]$ grep -i state /run/systemd/users/$(id -u) STATE=active [michel@localhost ~]$ pkexec whoami ==== AUTHENTICATING FOR org.freedesktop.policykit.exec ==== Authentication is needed to run `/usr/bin/whoami' as the super user Authenticating as: root Password: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie ==== AUTHENTICATION FAILED ==== Error executing command as another user: Not authorized This incident has been reported. [michel@localhost ~]$ ----------------------------------------------------------------- Resolution:
FIXED =>
(none) (In reply to Michel AUTEM from comment #25) > I would like to re-open this ticket, which was *never* resolved *at all*, at > least for five years and three versions of Mageia : I get still exactly the > same symptoms as Xuo in Mageia 7.1 ! > > This bug occurs *only* when I'm connected under my logId. Everything works > fine in any other account, "root" but also any *new* account I create. > > But suppressing *my* account and re-creating it (keeping /home ..) has no > effect : impossible to launch the MCC, and any appli needing "root" > privileges. Most likely cause is that you've previously used the su command (rather then su --login which can be abbreviated as just "su -"), and then run anything that updates files in /home leaving them owned by root. If that is the case, try running the following su - chown -Rc michel:michel /home/michel exit Replace all three occurrances of michel in the chown command with the user that is used on that system, if it isn't michel. Then see if the "pkexec whomai" works. Hi Dave, Your logic bears common sense : "something" seemed to have been changed or even corrupted, somewhere in my /home, that was like I had lost some privileges somewhere . But I don't see how that could be an effect of acting as "root" or any other logId .. I had already suppressed (renamed..) my .cache directory and that did *nothing*. Then I applied your command and .. that did nothing .. But good news now : looking again at the errors messages I got when launching MCC in a console, it came to Me in a flash : I opened "Session & Startup" in my Xfce tools, went in the "Application Automatic Startup" index, and there ... the "Policykit Authentication Agent" was *UNCHECKED* !! I re-checked it, rebooted the system, and now everything works again like a charm. Why ? How ? When ? Who ? Don't ask Me, I **NEVER** went there before ! Maybe that occurred when I installed/de-installed some component, and something could be extracted from the system logs, but I'm not clever enough in Linux. Best regards. You can't reopen this bug. Resolution:
(none) =>
FIXED Hi David, Not a problem, I just killed it .. ;-) |