Description of problem: Some programs that require root privileges will fail authentication when launched as a normal user. This seems to occur when running a light weight window manager such as fvwm2 or ICEwm, unsure about others as I have not tested. For example, when launching drakconf from a terminal as a normal user, entering the root password when prompted will fail as shown: [david@localhost ~]$ drakconf Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257. ==== 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. [david@localhost ~]$ In a lightweight window manager, the password dialogue box does not appear, although as can be seen, a password prompt is still presented. When launching from a menu entry, there is a silent failure. This issue is not restricted to drakconf. I have need for vmware (I know, commercial software, not supported, etc., etc.), but the issue seems to be identical. Launching vmware player (full vmware not yet tested) has the same failure when root privileges are requested: [david@localhost ~]$ vmplayer I/O warning : failed to load external entity "/etc/vmware/hostd/proxy.xml" ==== AUTHENTICATING FOR org.freedesktop.policykit.exec ==== Authentication is needed to run `/usr/lib/vmware/bin/vmware-setup-helper' 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. I mention vmware here not because vmware itself is at fault, but the software stack used by both vmware and drakconf to request root privileges does not function correctly in lightweight window managers. This problem does not occur using gnome, and presumably, other full featured desktop environments. Version-Release number of selected component (if applicable): This issue occurs in Mageia 8, 7, and 5. I am running 7.1 on bare metal and Cauldron (beta 2 iso) in VirtualBox. This problem (or something functionally identical) occurred in 5, but I did not record the details and just lived with it. The problem did not occur in the early days of Mageia. How reproducible: Every time. Steps to Reproduce: 1.Log in as a normal user using fvwm2 or ICEwm. (Other light WMs may have the problem as well.) 2.Launch drakconf from terminal or menu without root privileges. 3.If run from terminal, enter root password when prompted at the command line and observe the failure. else if run from menu, note silent failure. Note, I left severity as normal. As noted though, a workaround is to use a full featured desktop environment, but this is very annoying as I prefer a lightweight WM.
It sounds like you don't have a Polkit agent running. Do you have the package mate-polkit installed?
Yes, polkit, mate-polkit, and lib64polkit1_0 are all installed. Also, the polkit daemon is running.
Do you see the /usr/libexec/polkit-mate-authentication-agent-1 process running? If not, I'm guessing this could be an issue with the recent xdg-compliance (xdg-autostart) update.
CC: (none) => luigiwalser
Yes, I think this was the issue. Hopefully fixed in xdg-compliance-1.3.1-2.mga8.
polkit-authentication-agen-1 process is the one that is running: [david@localhost ~]$ ps -aux | grep polkit polkitd 1485 0.0 0.1 1933908 17924 ? Ssl Jan01 0:00 /usr/lib/polkit-1/polkitd --no-debug david 15021 0.0 0.0 9180 760 pts/11 S+ 15:08 0:00 grep --color polkit root 22936 0.0 0.0 11048 4880 tty2 T Jan03 0:00 /usr/lib/polkit-1/polkit-agent-helper-1 root [david@localhost ~]$
After installing the update, log out and log back in and you should have /usr/libexec/polkit-mate-authentication-agent-1 running and drakconf should work.
Ok, My Cauldron install is fully up to date, to include xdg-compliance-1.3.1-2.mga8. The problem remains. Unsurprisingly, this works while running Mate. In that case /usr/libexec/polkit-mate-authentication-agent-1 is running. It does not run while running fvwm2 or ICEwm.
What does: echo $SESSION show? If you run: xdg-autostart -v -d Old does it run /usr/libexec/polkit-mate-authentication-agent-1 ? If not, what do you see in the output mentioning that?
While running Cauldron and fvwm2: echo $SESSION returns nothing running: xdg-autostart -v -d Old does start /usr/libexec/polkit-mate-authentication-agent-1. output thus: /etc/xdg/autostart/polkit-mate-authentication-agent-1.desktop: Delayed by 0 s | /usr/libexec/polkit-mate-authentication-agent-1 starting drakconf as non privileged user presents the root password pop up window and mageia control center starts as expected.
Thanks. /etc/X11/Xsession is what should be calling that (via /etc/X11/xinit.d/xdg-autostart). What does: echo $DESKTOP give you? Probably nothing. What does this give you? /usr/sbin/chksession -F
While running Cauldron and fvwm2, weather or not xdg-autostart -v -d Old has been issued, echo $DESKTOP yialds no results, and /usr/sbin/chksession -f yields "Plasma"
This bug was for IceWM, not Plasma (where drakconf should have already been working fine). Please check in IceWM.
Note, in my previous comment, I was running fvwm2, not plasma. While running ICEwm, echo $DESKTOP yields no results, and /usr/sbin/chksession -F yelds "Plasma" just as it did while running fvwm2.
Hmm, I misread the script, so it just uses chksession -F if you choose "Default" in the display manager when logging in. The display manager is supposed to set the value of DESKTOP, but only for the life of that script, it doesn't export it so that it's available in your session. OK, let's do this to debug it. Add the following to a file called /etc/X11/xinit.d/sessdbg: # to be sourced echo $SESSION > /var/tmp/sessdbg then log in to fvwm2 or IceWM and see what: cat /var/tmp/sessdbg shows.
Hmmm.. /etc/X11/xinit.d/sessdbg did not exist. I created it with the contents: echo $SESSION > /var/tmp/sessdbg and made executable (chmod 755 sessdbg) of course. On subsequent login to ICEwm, /var/tmp/sessdbg does not exist, no doubt because echo $SESSION yielded no results.
No that won't work. It shouldn't be executable, and it needs to have the "# to be sourced" comment in it.
Removed executable permissions (chmod 644), added "# to be sourced" line. /var/tmp/sessdbg still does not exist.
Oops, my mistake. It still needs the executable permissions.
executable permissions restored. /var/log/sessdbg still does not exist.
What display manager are you using? GDM, SDDM, ? It may not be running Xsession correctly.
Whatever is the default out of the box. Appears to be GDM.
Assignee: bugsquad => gnome
Priority: Normal => release_blocker
if you edit /etc/X11/gdm/custom.conf and uncomment the "WaylandEnable=false" line: [daemon] # Uncomment the line below to force the login screen to use Xorg WaylandEnable=false and reboot, does it work then ?
I uncommented the line: WaylandEnable=false in /etc/X11/gdm/custom.conf This had no effect on the problem.
does it work better with: gdm-3.38.2.1-2.mga8 ?
upgrading to gdm-3.38.2.1-2.mga8 had no effect, whether or not WaylandEnable=false was commented out as above.
Can you try switching to SDDM (the Mageia control center in Boot > Set up display manager, gives you a way to do it), just to make sure there isn't something else we're missing? I do believe GDM is the problem, just want to be 100% sure there isn't also something else at play.
I think you may be on to something. SDDM worked.
Thanks. That'll probably be your best bet going forward. Apparently there's a known regression in GDM, and in typical GNOME fashion, people are taking the attitude that nothing matters but GNOME, which is entirely inappropriate for a display manager, which is supposed to be general enough to successfully log you into any window manager or desktop environment.
What known regression is that David, and who are those people? It looks more like a heap of old ugly hacks have stopped working. /etc/xdg/autostart/polkit-mate-authentication-agent-1.desktop contains OnlyShowIn=MATE;XFCE;OPENBOX;Old;X-Cinnamon; which requires XDG_CURRENT_DESKTOP to be set to one of the above. It is set to "Old" in /etc/X11/xinit.d/xdg-autostart if $SESSION matches icewm*|IceWM*|starticewm But $SESSION is currently not set to anything when started by GDM.
CC: (none) => mageia
Martin, don't be a smart alec too. What stopped working was something that was working fine for over 20 years and shouldn't have been changed. The SESSION variable is set in /etc/X11/Xsession, either to chksession -F if you choose "Default" in your display manager, or to the value of $DESKTOP which is set by the display manager to the name of the session you chose to log in (not default). GDM should still be running Xsession for non-GNOME sessions, not just trying to run xinit scripts directly itself.
Mageia isn't Devuan. We accept that things change and we have to adapt to that. I logged the value of SESSION in /etc/X11/Xsession when using LightDM, and this is what I got for various different sessions: SESSION=cinnamon-session-cinnamon SESSION=/usr/bin/fvwm2 SESSION=/usr/bin/gnome-session SESSION=startgnome_classic SESSION=/usr/bin/gnome-session SESSION=icewm SESSION=icewm-session SESSION=/usr/bin/startlxde SESSION=startmate SESSION=/usr/bin/startopenbox SESSION=/usr/bin/startplasma-x11 SESSION=startxfce4 By the time it got to /etc/X11/xinit.d/xdg-autostart this had changed to SESSION=cinnamon-session-cinnamon SESSION=fvwm2 SESSION=gnome-session SESSION=startgnome_classic SESSION=gnome-session SESSION=icewm SESSION=icewm-session SESSION=startlxde SESSION=startmate SESSION=startopenbox SESSION=startplasma-x11 SESSION=startxfce4 Turns out that if you don't have pulse audio installed, later scripts may not see what they expect! Take a look at the scripts in /etc/X11/xinit.d and see how many you think are broken, given the above (DESKTOP is set to the same as SESSION, but doesn't get changed). I have modified the GDM Xsession script to set DESKTOP and SESSION before running the xinit.d scripts. This fixes the reported bug for IceWM. Other lightweight DMs, such as fvwm2, have the fault regardless of which DM you use, because /etc/X11/xinit.d/xdg-autostart only handles IceWM.
(In reply to Martin Whitaker from comment #31) > Mageia isn't Devuan. We accept that things change and we have to adapt to > that. Well played sir :D > I logged the value of SESSION in /etc/X11/Xsession when using LightDM, and > this is what I got for various different sessions: > > [snip] > > By the time it got to /etc/X11/xinit.d/xdg-autostart this had changed to > > [snip] > > Turns out that if you don't have pulse audio installed, later scripts may > not see what they expect! Yes, you're right. > Take a look at the scripts in /etc/X11/xinit.d and see how many you think > are broken, given the above (DESKTOP is set to the same as SESSION, but > doesn't get changed). Also correct. It used to be that the Window Manager / Desktop Environment selections that you saw in your Display Manager came from files in /etc/X11/wmsession.d, in the format described here: https://wiki.mageia.org/en/How_to_add_a_new_Window_Manager_or_Display_Manager and the DESKTOP variable would be set to the value of NAME from the one that you chose. Then this was changed to use xdg desktop file format files in /usr/share/xsessions, which is a similar but slightly different format, and as you demonstrated, now DESKTOP is set to the TryExec value, not Name. I guess a lot of the xinit scripts were not reviewed when we made this transition. I can see the following are incorrect on my mga7 system: /etc/X11/xinit/XIM (from xinitrc) /etc/X11/xinit.d/libcanberra-gtk-module.sh (from canberra-gtk) /etc/X11/xinit.d/mgaapplet (from mgaonline) /etc/X11/xinit.d/xdg-user-dirs-update-gtk (from xdg-user-dirs-gtk) Yikes! > I have modified the GDM Xsession script to set DESKTOP and SESSION before > running the xinit.d scripts. This fixes the reported bug for IceWM. Other > lightweight DMs, such as fvwm2, have the fault regardless of which DM you > use, because /etc/X11/xinit.d/xdg-autostart only handles IceWM. That's true. I don't see anything in the fvwm2 package itself that handles starting a polkit agent, so I can't imagine this was even working in fvwm2 before.
Status?
CC: (none) => davidwhodgins
TODO: fix xinit scripts
We are back to the same state as Mageia 7 (and earlier), so I would leave the xinit cleanup as a high priority task for Mageia 9.
So there is no problem for one-DE install of any of MATE, Xfce, Cinnamon, Plasma, Gnome? Then I agree to lower it from release blocker. Users running lightweight desktops are generally more friends with CLI. To put in errata: If user experience this, in terminal become root and urpmi <what> ? i.e some polkit agent? Or some other method.
Priority: release_blocker => HighKeywords: (none) => FOR_ERRATA8Target Milestone: --- => Mageia 9CC: (none) => friSummary: Under certain circumstances, some (all?) programs that require root privileges will fail authentication when launched as normal user. => On some lightweight desktops only install, programs that require root privileges will fail authentication when launched as normal user.
Nothing is needed except fixing the xinit scripts. Been busy, on my TODO list (others are free to help). Original bug should be okay already.
Target Milestone: Mageia 9 => ---Keywords: FOR_ERRATA8 => (none)
> I guess a lot of the xinit scripts were not reviewed when we made this > transition. I can see the following are incorrect on my mga7 system: > /etc/X11/xinit/XIM (from xinitrc) Could be fixed, but it's looking for commands like ami_applet and wmami that don't exist any more, so not very impactful... > /etc/X11/xinit.d/libcanberra-gtk-module.sh (from canberra-gtk) If fixed would just prevent setting an environment variable on GNOME which is probably harmless anyway... > /etc/X11/xinit.d/mgaapplet (from mgaonline) Presumably prevents mgaapplet from running any more in IceWM and Fluxbox unless this gets fixed, unless we've come up with some other way to make it run there. I'm not sure if anyone has checked that. Would need to be fixed in git though, rather than the package. > /etc/X11/xinit.d/xdg-user-dirs-update-gtk (from xdg-user-dirs-gtk) xinit file was supposed to make xdg-user-dirs-gtk-update run when logging into GNOME, KDE, and XFce, but I think /usr/share/autostart/user-dirs-update-gtk.desktop handles that now. Did you see any other scripts that could be fixed Martin?
> > /etc/X11/xinit.d/mgaapplet (from mgaonline) > > Presumably prevents mgaapplet from running any more in IceWM and Fluxbox > unless this gets fixed, unless we've come up with some other way to make it > run there. I'm not sure if anyone has checked that. Would need to be fixed > in git though, rather than the package. So I asked about this on the qa-discuss list and people responded on IRC. It sounds like mgaapplet is running in IceWM. mgaonline does have a /etc/xdg/autostart/mageia-mgaonline.desktop file. In fact, so /etc/X11/xinit.d/xdg-autostart, which I fixed earlier in this bug should be running that. So it doesn't sound like any of these scripts really *need* to be fixed. Some could be trimmed or removed.