Bug 28010 - Under certain circumstances, some (all?) programs that require root privileges will fail authentication when launched as normal user.
Summary: Under certain circumstances, some (all?) programs that require root privilege...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker normal
Target Milestone: ---
Assignee: GNOME maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-03 21:59 CET by David Savolainen
Modified: 2021-01-14 22:45 CET (History)
2 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description David Savolainen 2021-01-03 21:59:09 CET
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.
Comment 1 David Walser 2021-01-04 17:13:00 CET
It sounds like you don't have a Polkit agent running.  Do you have the package mate-polkit installed?
Comment 2 David Savolainen 2021-01-04 17:57:30 CET
Yes, polkit, mate-polkit, and lib64polkit1_0 are all installed.  Also, the polkit daemon is running.
Comment 3 David Walser 2021-01-04 20:34:32 CET
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

Comment 4 David Walser 2021-01-04 21:55:36 CET
Yes, I think this was the issue.

Hopefully fixed in xdg-compliance-1.3.1-2.mga8.
Comment 5 David Savolainen 2021-01-04 22:09:29 CET
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 ~]$
Comment 6 David Walser 2021-01-04 22:46:48 CET
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.
Comment 7 David Savolainen 2021-01-05 00:44:05 CET
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.
Comment 8 David Walser 2021-01-05 00:51:07 CET
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?
Comment 9 David Savolainen 2021-01-05 05:27:37 CET
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.
Comment 10 David Walser 2021-01-05 16:13:41 CET
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
Comment 11 David Savolainen 2021-01-05 19:17:41 CET
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"
Comment 12 David Walser 2021-01-05 19:29:42 CET
This bug was for IceWM, not Plasma (where drakconf should have already been working fine).  Please check in IceWM.
Comment 13 David Savolainen 2021-01-05 19:42:03 CET
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.
Comment 14 David Walser 2021-01-05 19:52:25 CET
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.
Comment 15 David Savolainen 2021-01-05 20:10:25 CET
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.
Comment 16 David Walser 2021-01-05 20:24:01 CET
No that won't work.  It shouldn't be executable, and it needs to have the "# to be sourced" comment in it.
Comment 17 David Savolainen 2021-01-05 20:36:02 CET
Removed executable permissions (chmod 644), added "# to be sourced" line.  /var/tmp/sessdbg still does not exist.
Comment 18 David Walser 2021-01-05 20:41:12 CET
Oops, my mistake.  It still needs the executable permissions.
Comment 19 David Savolainen 2021-01-05 21:06:03 CET
executable permissions restored.  /var/log/sessdbg still does not exist.
Comment 20 David Walser 2021-01-05 21:31:23 CET
What display manager are you using?  GDM, SDDM, ?  It may not be running Xsession correctly.
Comment 21 David Savolainen 2021-01-05 21:36:03 CET
Whatever is the default out of the box.  Appears to be GDM.
David Walser 2021-01-05 21:58:55 CET

Assignee: bugsquad => gnome

David Walser 2021-01-05 21:59:20 CET

Priority: Normal => release_blocker

Comment 22 Thomas Backlund 2021-01-08 14:03:57 CET
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 ?
Comment 23 David Savolainen 2021-01-08 14:52:27 CET
I uncommented the line:

WaylandEnable=false

in /etc/X11/gdm/custom.conf

This had no effect on the problem.
Comment 24 Thomas Backlund 2021-01-08 16:18:56 CET

does it work better with: gdm-3.38.2.1-2.mga8 ?
Comment 25 David Savolainen 2021-01-08 19:23:26 CET
upgrading to gdm-3.38.2.1-2.mga8 had no effect, whether or not WaylandEnable=false was commented out as above.
Comment 26 David Walser 2021-01-08 19:32:33 CET
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.
Comment 27 David Savolainen 2021-01-08 19:43:48 CET
I think you may be on to something.  SDDM worked.
Comment 28 David Walser 2021-01-08 19:46:27 CET
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.
Comment 29 Martin Whitaker 2021-01-08 22:13:38 CET
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

Comment 30 David Walser 2021-01-08 22:24:46 CET
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.
Comment 31 Martin Whitaker 2021-01-13 01:55:20 CET
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.
Comment 32 David Walser 2021-01-14 22:45:55 CET
(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.

Note You need to log in before you can comment on or make changes to this bug.