In Mageia 5, after logging out and then back in to a KDE user session MCC (drakconf) can no be started by the user because the authentication GUI will no longer appear. This issue very much resembles the one claimed to have been resolved in Bug 11184, though I'm filing this one against KDE. Attempting to start drakconf via cli results in: [john@purgatory ~]$ drakconf Error executing command as another user: Not authorized This incident has been reported. --- The above resembles the behaviour described by Frank Griffin in Bug 12572, however no remote login/ssh is involved. How reproducible: Always. Tested on both i586 and x86_64. Steps to Reproduce: 1. Cold boot a Mageia 5 box and log into KDE. Attempt to start drakconf. All will appear to be functioning as expected. You will be prompted for the root password. 2. Log out of that user and back in. Do as in step #1 above, but now the launcher icon fails to respond and the CLI will report "Not authorized". 3. If another user id is available on the system, log out of the first user and in as the second user. drakconf WILL start normally for the second user. 4. Log out of the second user and back in as either user. drakconf will NOW FAIL to authenticate for both. polkit packages installed: lib64polkit1_0-0.113-1.mga5 polkit-kde-agent-1-0.99.1-2.mga5 lib64mate-polkit1_0-1.8.0-6.mga5 lib64polkit-qt-agent-1_1-0.112.0-6.mga5 mate-polkit-1.8.0-6.mga5 polkit-0.113-1.mga5 lib64polkit-qt-core-1_1-0.112.0-6.mga5 lib64polkit-gir1.0-0.113-1.mga5 Reproducible: Steps to Reproduce:
@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=90818Assignee: bugsquad => mageiaSource RPM: (none) => systemd-217-11.mga5
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
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 => HighCC: (none) => doktor5000
(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 => ASSIGNEDAssignee: mageia => doktor5000Summary: MCC won't start after logging out/in to KDE session => MCC won't start after logging out/in to KDE session - session recognised by polkit as "online" vs. "active"
(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!
CC: (none) => wilcal.int
CC: (none) => davidwhodginsWhiteboard: MGA5-64-OK => MGA5-64-OK advisory
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2015-0145.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
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 => NormalStatus: RESOLVED => REOPENEDCC: (none) => xuoyResolution: FIXED => (none)Severity: normal => minor
Keywords: validated_update => (none)CC: (none) => mageia
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_updateStatus: REOPENED => RESOLVEDResolution: (none) => FIXED
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)Status: RESOLVED => UNCONFIRMEDEver confirmed: 1 => 0
(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) => FIXEDStatus: UNCONFIRMED => RESOLVED
Hi David, Not a problem, I just killed it .. ;-)