LXQT sudo doesn't work, applications don't open

Hello.

Recently, i’ve been trying out LXQT, and I’ve noticed that whenever I try to open any of the YaST programs after entering my password into LXQT sudo, the programs never open up. YaST itself however, opens up just fine.
I’ve looked into the systemd journal to find the problem regarding YaST sudo, and this is what comes up -

su[25225]   gkr-pam: unable to locate daemon control file
su[25225]   gkr-pam: stashed password to try later in open session
lxqt-sudo[25223]   [13]
su[25225]   (to root) computer on pts/1
su[25225]   pam_unix(su:session): session opened for user root(uid=0) by (uid=1000)
lxqt-sudo[25223]   bash: /sbin/yast2 bootloader: No such file or directory
su[25225]   pam_unix(su:session): session closed for user root

Apparently, the program I’m trying to open doesn’t exist, which makes no sense whatsoever. Doing the same thing in a different DE works fine.
Does anyone know why LXQT sudo doesn’t work here?

It isn’t clear what you are doing. As a result, I am not sure what to do to test this.

For me, “sudo” is a command that I enter at a terminal session. But I can’t tell if that is what you are doing.

All the steps that summarize what I’m doing are as follows -

  1. open up any yast program, except YaST itself (ex. YaST time and date, YaST software, YaST bootloader, YaST printer)
  2. enter in your password when LXQT sudo window appears
  3. profit (nothing comes up)

The code in my post is not from a terminal session, it is from the logs in the systemd journal. Apologies for not specifying. If it was from the terminal itself, I would’ve just asked about “sudo” rather than “LXQT sudo”

Hi
I imagine the yast2-bootloader module is not installed since it can’t find it…

You probably aren’t using “sudo” at all. You may be using the menus, and perhaps they use “xdg-su” to start some applications.

I ran some tests on my Gnome Tumbleweed, but because you’re calling YaST from a terminal the DE shouldn’t make any difference. Of course, before any testing, I ran a “zypper dup” to ensure my Tumbleweed was fully updated.

I never have used “sudo” to invoke YaST, but I regularly use “su” so this was an interesting exploration.
I also ran these commands on LEAP 15.2 which surprisingly (to me) caused different sudo problems although “su” worked fine for me on both distros… throwing user permission error warnings but successfully invoking the YaST control panel and the software management module.

On my Tumbleweed…
Logged in as a normal User first.

I then opened a Gnome Terminal window (but can be any) and ran the following tests…

I first ran the following and the result was surprising… It launched YaST in ncurses mode, not the GUI YaST2, and it didn’t prompt me to enter credentials to elevate permissions(!). I’m contemplating whether this is a bug that needs to be reported, my initial thought is that this is a potential security issue.

sudo yast2

I then launched ncurses YaST by calling it directly and I was properly challenged for credentials

sudo yast

I then launched the YaST Software Management module directly as follows and the command threw the following error and failed silently.

sudo yast2 sw_single &
[1] 7826

I then repeated the above tests but from an elevated console which was accomplished by the following command. Note that there is no need or difference to re-login as root with a “su -”, simple elevation of permissions is all that is needed.
I do this regularly on LEAP, so was curious to see if I would see anything different…

From the elevated terminal, the following launched the YaST control panel in GUI mode as expected. Note that during my testing with re-logins, for unknown reasons ncurses mode was launched instead. After closing that terminal window and opening a new terminal window, normal behavior resumed

# yast2

I then ran the following command to open the YaST Software Management module successfully

# yast2 sw_single &

So.
Bottom line is that sudo has some issues launching YaST.
But, “su” works as expected.

This appears to be another example which illustrates true switching to root permissions using “su” vs simply impersonating using “sudo”
In openSUSE, you can “sudo” all you want, but “su” is encouraged and is actually what must be done in some situations.

TSU

First, you’ll find it easier to read your system log in real time if the entries you want are related to an event you can invoke on demand instead of searching your logs.
To do this, simply open a terminal window and run the following command

sudo journalctl -f

Inspecting what you posted, I suspect that you tried to open the YaST bootloader module, but that’s an incorrect command which is why it failed. You need to add the “&” on the end as follows(reminding that you should run this from a terminal elevated using the “su” command). This is the real reason why the file doesn’t exist… Your command has to reference the file properly.

# yast2 bootloader &

TSU

Not sure if you are still looking for a solution, but this very problem has bothered me as well. Tonight, I decided to track down this very annoying issue that haunts LXQT for years. As you probably know, when you click on the menu items related to Yast2 it involves xdg-su.

Unfortunately, there is a bug in /usr/bin/xdg-su

Line 564 (at least on SUSE Leap 15.3):
$LXQTSU -s “$cmd”

must read:
$LXQTSU -s $cmd

to properly parse the Yast2 subcommand (e.g. sw_single) to lxqt-sudo. Remove the quotation marks and all your Yast menu items are back in business. I think this is worth implementing by default in any future SUSE release.

Hope this helps.
Aicko

Created an account just to thank you for publishing the solution. Can confirm both the problem and the solution are relevant in 2022.

Although it appears to work in this simple case, the solution is wrong. It will cause command to be expanded in the wrong moment. Given that other su/sudo wrappers apparently work in this case, I’d rather consider it LXQt bug.