YAST Login is using xdg-su instead of KDE GUI Prompt

Just updated this afternoon from 15.3 to 15.4.

When logging in to Yast, I no longer get the usual KDE GUI prompt. Instead I get a prompt using: “xdg-su: /sbin/yast2”. After entering the root password, I get Yast opening as usual. The prompt for the login remains until Yast is closed.

If I look at the prompt dialog box while Yast is open, I see the following:

1000 GID 100
QStandard Paths: runtime directory '/run/user/1000' is not owned by UID 0, but a directory permissions 0700 owned by UID 1000 GID 100'

I’d like to get the standard KDE GUI prompt back. How can I do this? I have done some research and apparently this message is harmless, so I could ignore it, but I’d like to have the expected behavior back.

As there could be a connection between your problem and the upgrade (and you see this possibilty also because you mention the fresh upgrade), please explain how you did the upgrade (there are several ways to do this).

You mean you start YaST from the main menu (or from an icon in the task bar or similar). That is before login.

Just for information. My 15.4 (upgraded from 15.3 using the on–line method months ago) inspecting the YaST icon from my KDE panel, it tells me that it will execute

/usr/bin/xdg-su -c /sbin/yast2

And what happens when I click on it looks all rather normal to me like it did for years.

Could you check from a shell if XDG_CURRENT_DESKTOP is set to KDE:


> env |grep XDG_CURRENT_DESKTOP
**XDG_CURRENT_DESKTOP**=KDE

and if package kde-cli-tools5 is installed


> LANG=C zypper se -s  kde-cli-tools5               
Loading repository data... 
Reading installed packages... 

S | Name                | Type    | Version           | Arch   | Repository 
--+---------------------+---------+-------------------+--------+----------------- 
i | kde-cli-tools5      | package | 5.24.4-bp154.1.23 | x86_64 | Haupt-Repository 
i | kde-cli-tools5-lang | package | 5.24.4-bp154.1.23 | noarch | Haupt-Repository

On host erlangen yast shows expected behavior. I executed:

karl@erlangen:~> **xdg-su -c yast2** 
karl@erlangen:~> 

Journal:

karl@erlangen:~> **journalctl -b --user --identifier sudo** 
Sep 28 11:11:23 erlangen sudo[831]: **    karl : TTY=pts/4 ; PWD=/home/karl ; USER=root ; COMMAND=/usr/sbin/yast2**
Sep 28 11:11:23 erlangen sudo[831]: pam_unix(sudo:session): session opened for user root(uid=0) by karl(uid=1000) 
Sep 28 11:11:30 erlangen sudo[831]: pam_unix(sudo:session): session closed for user root 
karl@erlangen:~> 

What is logged to journal on your machine?

I mean from the desktop, I open the Start Menu and click the entry for Yast.

The upgrade was done precisely following the recommended method on the openSUSE Web site, per here: SDB:System upgrade to Leap 15.5 - openSUSE Wiki
It was therefore an online upgrade which went through with zero issues except 31 packages which had to be explicitly changed to other vendors in in response to the queries issued about that during the upgrade. In other words, normal, no visible problems during the upgrade.

Results for the above commands:

env |grep XDG_CURRENT_DESKTOP 
**XDG_CURRENT_DESKTOP**=KDE

[FONT=monospace]zypper se -s  kde-cli-tools5  
Loading repository data... 
Reading installed packages... 

S  | Name                | Type       | Version           | Arch   | Repository 
---+---------------------+------------+-------------------+--------+----------------------------------------------- 
i+ | kde-cli-tools5      | package    | 5.24.4-bp154.1.23 | x86_64 | Main Repository 
i+ | kde-cli-tools5      | package    | 5.24.4-bp154.1.23 | x86_64 | openSUSE-Leap-15.4-DVD-x86_64-Build243.2-Media 
   | kde-cli-tools5      | srcpackage | 5.24.4-bp154.1.23 | noarch | Source Repository 
   | kde-cli-tools5      | srcpackage | 5.18.5-bp154.1.8  | noarch | Source Repository 
i+ | kde-cli-tools5-lang | package    | 5.24.4-bp154.1.23 | noarch | Main Repository 
i+ | kde-cli-tools5-lang | package    | 5.24.4-bp154.1.23 | noarch | openSUSE-Leap-15.4-DVD-x86_64-Build243.2-Media

[/FONT]

The xdg-su script has a generic fallback mode that starts “su -c” in an xterm if the current desktop is not set in the environment or if kdesu is not present. But this looks ok for me.
So please start this command in a shell:


> bash -x /usr/bin/xdg-su -c /sbin/yast2 2>xdg-su.log

close yast and post the xdg-su.log file.

I will reiterate what I said before: before this upgrade, when I clicked on the Yast menu item, I was prompted with a KDE password dialog box, requesting the root password. Now I get a smaller dialog box with an X in the upper left corner, with the window title saying “xdg:su: /sbin/yast2”. This is not a KDE dialog box as far as I can see.

Executing your command above to the journal immediately after clicking on the Yast menu and opening the dialog box shows me only this:

journalctl -b --user --identifier sudo 
Sep 27 14:12:36 localhost.localdomain sudo[9739]: pam_kwallet5(sudo:auth): pam_kwallet5: pam_sm_authenticate
Sep 27 14:12:36 localhost.localdomain sudo[9739]: **pam_kwallet5(sudo:auth): pam_kwallet5: Couldn't get password (it is empty)**
Sep 27 14:12:41 localhost.localdomain sudo[9739]: **   rhack : TTY=pts/1 ; PWD=/home/rhack ; USER=root ; COMMAND=/usr/bin/zypper update**
Sep 27 14:12:41 localhost.localdomain sudo[9739]: pam_kwallet5(sudo:setcred): pam_kwallet5: pam_sm_setcred
Sep 27 14:12:41 localhost.localdomain sudo[9739]: pam_unix(sudo:session): session opened for user root by rhack(uid=1000) 
Sep 27 14:12:41 localhost.localdomain sudo[9739]: pam_kwallet5(sudo:session): pam_kwallet5: pam_sm_open_session
Sep 27 14:12:41 localhost.localdomain sudo[9739]: pam_kwallet5(sudo:session): pam_kwallet5: not a graphical session, skipping. Use force_run parameter to ignore this. 
Sep 27 14:12:57 localhost.localdomain sudo[9739]: pam_unix(sudo:session): session closed for user root 
Sep 27 14:12:57 localhost.localdomain sudo[9739]: pam_kwallet5(sudo:session): pam_kwallet5: pam_sm_close_session
Sep 27 14:12:57 localhost.localdomain sudo[9739]: pam_kwallet5(sudo:setcred): pam_kwallet5: pam_sm_setcred
Sep 27 14:37:01 localhost.localdomain sudo[17357]: pam_kwallet5(sudo:auth): pam_kwallet5: pam_sm_authenticate
Sep 27 14:37:01 localhost.localdomain sudo[17357]: **pam_kwallet5(sudo:auth): pam_kwallet5: Couldn't get password (it is empty)**
Sep 27 14:37:08 localhost.localdomain sudo[17357]: **pam_kwallet5(sudo:auth): pam_kwallet5: Prompt for password failed Conversation error**
Sep 27 14:37:08 localhost.localdomain sudo[17357]: **pam_unix(sudo:auth): auth could not identify password for [root]**
Sep 27 14:37:10 localhost.localdomain sudo[17396]: pam_kwallet5(sudo:auth): pam_kwallet5: pam_sm_authenticate
Sep 27 14:37:10 localhost.localdomain sudo[17396]: **pam_kwallet5(sudo:auth): pam_kwallet5: Couldn't get password (it is empty)**
Sep 28 03:47:48 localhost.localdomain sudo[26555]: pam_kwallet5(sudo:auth): pam_kwallet5: pam_sm_authenticate
Sep 28 03:47:48 localhost.localdomain sudo[26555]: **pam_kwallet5(sudo:auth): pam_kwallet5: Couldn't get password (it is empty)**
Sep 28 03:47:54 localhost.localdomain sudo[26555]: **   rhack : TTY=pts/1 ; PWD=/Data2/Work ; USER=root ; COMMAND=/usr/bin/zypper refresh**
Sep 28 03:47:54 localhost.localdomain sudo[26555]: pam_kwallet5(sudo:setcred): pam_kwallet5: pam_sm_setcred
Sep 28 03:47:54 localhost.localdomain sudo[26555]: pam_unix(sudo:session): session opened for user root by rhack(uid=1000) 
Sep 28 03:47:54 localhost.localdomain sudo[26555]: pam_kwallet5(sudo:session): pam_kwallet5: pam_sm_open_session
Sep 28 03:47:54 localhost.localdomain sudo[26555]: pam_kwallet5(sudo:session): pam_kwallet5: not a graphical session, skipping. Use force_run parameter to ignore this. 
Sep 28 03:48:10 localhost.localdomain sudo[26555]: pam_unix(sudo:session): session closed for user root 
Sep 28 03:48:10 localhost.localdomain sudo[26555]: pam_kwallet5(sudo:session): pam_kwallet5: pam_sm_close_session
Sep 28 03:48:10 localhost.localdomain sudo[26555]: pam_kwallet5(sudo:setcred): pam_kwallet5: pam_sm_setcred
Sep 28 03:53:13 localhost.localdomain sudo[28610]: pam_kwallet5(sudo:auth): pam_kwallet5: pam_sm_authenticate
Sep 28 03:53:13 localhost.localdomain sudo[28610]: **pam_kwallet5(sudo:auth): pam_kwallet5: Couldn't get password (it is empty)**
Sep 28 03:53:20 localhost.localdomain sudo[28610]: **   rhack : TTY=pts/1 ; PWD=/Data2/Work ; USER=root ; COMMAND=/usr/bin/zypper refresh**
Sep 28 03:53:20 localhost.localdomain sudo[28610]: pam_kwallet5(sudo:setcred): pam_kwallet5: pam_sm_setcred
Sep 28 03:53:20 localhost.localdomain sudo[28610]: pam_unix(sudo:session): session opened for user root by rhack(uid=1000) 
Sep 28 03:53:20 localhost.localdomain sudo[28610]: pam_kwallet5(sudo:session): pam_kwallet5: pam_sm_open_session
Sep 28 03:53:20 localhost.localdomain sudo[28610]: pam_kwallet5(sudo:session): pam_kwallet5: not a graphical session, skipping. Use force_run parameter to ignore this. 
Sep 28 03:53:32 localhost.localdomain sudo[28610]: pam_unix(sudo:session): session closed for user root 
Sep 28 03:53:32 localhost.localdomain sudo[28610]: pam_kwallet5(sudo:session): pam_kwallet5: pam_sm_close_session
Sep 28 03:53:32 localhost.localdomain sudo[28610]: pam_kwallet5(sudo:setcred): pam_kwallet5: pam_sm_setcred

Note that all of those lines are referring to actions taken BEFORE I opened the Yast dialog. So I don’t see how they relate.

Again, I’m assuming that the KDE dialog box I used to have is the expected behavior on openSUSE 15.4. Has it been changed for some reason to this new dialog?

And what does the message inside the box about runtime directory is not owned by UID 0 mean?

OK, here it is:

+ check_common_commands -c /sbin/yast2
+ '' 2 -gt 0 ']'
+ parm=-c
+ shift
+ case "$parm" in
+ '' 1 -gt 0 ']'
+ parm=/sbin/yast2
+ shift
+ case "$parm" in
+ '' 0 -gt 0 ']'
+ '' -z '' ']'
+ unset XDG_UTILS_DEBUG_LEVEL
+ '' 0 -lt 1 ']'
+ xdg_redirect_output=' > /dev/null 2> /dev/null'
+ '' x-c '!=' x ']'
+ user=
+ cmd=
+ '' 2 -gt 0 ']'
+ parm=-c
+ shift
+ case "$parm" in
+ '' -z /sbin/yast2 ']'
+ cmd=/sbin/yast2
+ shift
+ '' 0 -gt 0 ']'
+ '' -z /sbin/yast2 ']'
+ detectDE
+ unset GREP_OPTIONS
+ '' -n KDE ']'
+ case "${XDG_CURRENT_DESKTOP}" in
+ DE=kde
+ '' xkde = x ']'
+ '' xkde = x ']'
+ '' xkde = x ']'
+ '' xkde = xgnome ']'
+ '' -f /run/user/1000/flatpak-info ']'
+ '' xkde = x ']'
+ case "$DE" in
+ su_kde
+ '' x5 = x4 ']'
++ which kdesu
+ KDESU=
+ '' 1 -eq 0 ']'
+ su_generic
+ '' -z '' ']'
+ xterm -geom 60x5 -T 'xdg-su: /sbin/yast2' -e su -c /sbin/yast2
+ '' 0 -eq 0 ']'
+ exit_success
+ '' 0 -gt 0 ']'
+ exit 0


The “which kdesu” command fails according to your log and so the script starts the generic fallback.


...
+ case "$DE" in
+ su_kde
+ '' x5 = x4 ']'
**++ which kdesu
+ KDESU=
+ '' 1 -eq 0 ']'**
+ su_generic
+ '' -z '' ']'´
q+ xterm -geom 60x5 -T 'xdg-su: /sbin/yast2' -e su -c /sbin/yast2

unfortunately the script sends the error output of which to /dev/null.
Please execute these commands


> which kdesu


> rpm -V kde-cli-tools5

OK, results are:

[FONT=monospace]which: no kdesu in (/home/rhack/.local/bin:/home/rhack/bin:/usr/local/bin:/usr/bin:/bin:/snap/bin)
[/FONT]
[FONT=monospace] rpm -V kde-cli-tools5 
missing     /usr/bin/kdesu
[/FONT]

Well, that seems to be the issue! However, I look for kdesu in the openSUSE Software site, and it says there is no official package for 15.4, only a community package for version 5.97 - and those are both source rpms.

So apparently kdesu is deprecated for 15.4?? Why isn’t this mentioned in the Release Notes? Why on earth would they simply drop this functionality?

OK, so I found someone on a site who complained about the same thing, and he was advised to use cnf to determine what package contained kdesu and to install that.

So I ran cnf and I got this:

[FONT=monospace]cnf kdesu 
                        
The program 'kdesu' can be found in following packages: 
  * kde-cli-tools5  path: /usr/bin/kdesu, repository: zypp (openSUSE-Leap-15.4-DVD-x86_64-Build243.2-Media) ] 
  * kde-cli-tools5  path: /usr/bin/kdesu, repository: zypp (repo-oss) ] 

Try installing with: 
    sudo zypper install kde-cli-tools5

So I tried installng that package, and I got this:

[/FONT]

[FONT=monospace]sudo zypper install kde-cli-tools5 
Loading repository data... 
Reading installed packages... 
'kde-cli-tools5' is already installed. 
No update candidate for 'kde-cli-tools5-5.24.4-bp154.1.23.x86_64'. The highest available version is already installed. 
Resolving package dependencies... 
Nothing to do.
[/FONT]

So I did a whereis to see where kdesu is if it’s anywhere, and I got this:

[FONT=monospace]whereis kdesu 
kdesu: /usr/share/man/man1/kdesu.1.gz

That’s just the man page. So what happened to the kdesu binary?

So I unconditionally updated the kde-cli-tools which reinstalled it. Then I run whereis again and I see I now have the kdesu utility in /usr/bin:

[/FONT]

[FONT=monospace]whereis kdesu                      
kdesu: /usr/bin/kdesu /usr/share/man/man1/kdesu.1.gz
[/FONT]

I’'m going to reboot now and see if anything changes. Back in a minute.

Bingo! Everything back to normal. I don’t know how the /bin/kdesu got deleted, must have been a glitch during the upgrade, as I haven’t been mucking about in there at all.

Now when I hit the Yast menu option, I get the usual KDE root password dialog box.

Thanks for the help - and the help of a couple people on other sites who had similar problems. We can mark this one resolved.

karl@erlangen:~> **ll Schreibtisch/org.opensuse.YaST.desktop** 
lrwxrwxrwx 1 karl users 49 21. Sep 08:16 Schreibtisch/org.opensuse.YaST.desktop -> /usr/share/applications/org.opensuse.YaST.desktop 
karl@erlangen:~> **cat /usr/share/applications/org.opensuse.YaST.desktop** 
[Desktop Entry] 
Type=Application 
Categories=Settings;System;X-SuSE-Core-System;X-SuSE-ControlCenter-System;X-GNOME-SystemSettings; 
Name=YaST 
Icon=yast-control-center 
GenericName=Administrator Settings 
Exec=**/usr/bin/xdg-su -c /sbin/yast2** 
Encoding=UTF-8 
Comment=Manage system-wide settings 

karl@erlangen:~>