Failure to launch authentication prompt on Ubuntu 24.04 LTS

[ToeKneeFan]

xrdp version

0.9.24

Detailed xrdp version, build options

xrdp 0.9.24
  A Remote Desktop Protocol Server.
  Copyright (C) 2004-2020 Jay Sorg, Neutrino Labs, and all contributors.
  See https://github.com/neutrinolabs/xrdp for more information.

  Configure options:
      --enable-ipv6
      --enable-jpeg
      --enable-fuse
      --enable-rfxcodec
      --enable-opus
      --enable-painter
      --enable-vsock
      --build=x86_64-linux-gnu
      --prefix=/usr
      --includedir=${prefix}/include
      --mandir=${prefix}/share/man
      --infodir=${prefix}/share/info
      --sysconfdir=/etc
      --localstatedir=/var
      --disable-silent-rules
      --libdir=${prefix}/lib/x86_64-linux-gnu
      --libexecdir=${prefix}/lib/x86_64-linux-gnu
      --disable-maintainer-mode
      --disable-dependency-tracking
      --with-socketdir=/run/xrdp/sockdir
      build_alias=x86_64-linux-gnu
      CFLAGS=-g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/build/xrdp-Fn5kxo/xrdp-0.9.24=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/xrdp-Fn5kxo/xrdp-0.9.24=/usr/src/xrdp-0.9.24-4
      LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now -Wl,--as-needed
      CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=3
      PKG_CONFIG_PATH=/build/xrdp-Fn5kxo/xrdp-0.9.24/pkgconfig

  Compiled with OpenSSL 3.0.13 30 Jan 2024

Operating system & version

Ubuntu 24.04.1 LTS

Installation method

dnf / apt / zypper / pkg / etc

Which backend do you use?

xorgxrdp

What desktop environment do you use?

GNOME

Environment xrdp running on

Physical machine with Intel HD Graphics 630

What's your client?

Microsoft Remote Desktop on Microsoft Windows 11

Area(s) with issue?

Authentication

Steps to reproduce

1. While logged in through xrdp, attempt to perform a GUI action that requires administrative/sudo privileges, such as adding a user.

✔️ Expected Behavior

We expect for an authentication prompt to appear and ask for a password.

❌ Actual Behavior

Nothing happens. Actions requiring sudo privileges are ignored.

Anything else?

OS release relationship
This problem appears to be new to Ubuntu 24.04 LTS and was not present on the prior LTS version (22.04 LTS). That is, the expected authentication prompts appeared when GUI actions required it. It may not necessarily be related to xrdp; this could be a polkit or GNOME issue.

Previous reports
This problem has been noted by a different user on StackOverflow. This was also noted on the c-nergy blog, which describes that expected polkit AUTH_ADMIN rules do not work:

Using the code above, you will be able to add users when remotely connect to your ubuntu machine. You would notice that no password prompt is required to perform this action. Normally, you could modify the exception rules and set multiple control level. The code below should prompt for password… However, this code does not seems to work !!! If time permits, we will investigate a little bit further

Unrelated issues/solutions
My .xsessionrc file consists of the following:

export GNOME_SHELL_SESSION_MODE=ubuntu
export XDG_CURRENT_DESKTOP=ubuntu:GNOME
export XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdg
export XAUTHORITY=/home/<redacted>/.Xauthority

That is, I have already configured xrdp to use the Ubuntu GNOME environment, rather than the default GNOME one. The problem reported on "Running GNOME on Ubuntu 24.04 LTS" is unrelated.

The solution proposed in "Why can't I perform some privileged GUI actions?" and @matt335672's pk-local is very helpful but is not applicable in this scenario, as pk-local adds polkit rules, including AUTH_ADMIN rules, but those rules cannot call the authentication prompt (as noted above).

This problem appears unrelated to #3053, which reports a different issue with Ubuntu 24.04 LTS. The error in this report is actually more similar to the problem described in #2926, which details a similar authentication-prompt issue on Xfce (may be the exact same problem, except on a different OS); that issue appears to have been closed prematurely due to nonresponse by the OP, so I am opening this one (especially as it is unclear if it is the same problem).

[ToeKneeFan]

It may also be noteworthy that GNOME Remote Desktop (the default RDP server in Ubuntu, the one that appears in Ubuntu settings) does not have this problem. By default, for GNOME Remote Desktop, authentication prompts appear when a superuser GUI action is performed (e.g., adding a new user).

Thus, although I mentioned that this could be a GNOME or polkit problem, it is mediated by an interaction with xrdp in a manner not replicated with GNOME Remote Desktop.

[matt335672]

Thanks for the high quality issue report @ToeKneeFan.

I'm a bit snowed under to look at this in a lot of detail currently, but I think what you're saying is, the link between the polkit daemon the polkit authentication agent for GNOME appears to be not working. Is that correct?

[matt335672]

Also, can you pick a scenario you'd like to look at and we'll step through it.

[matt335672]

FWIW, on my machine I get an authentication prompt in a GNOME xrdp session with this command as an unprivileged user:-

pkexec whoami

[ToeKneeFan]

Thanks for the high quality issue report @ToeKneeFan.

I'm a bit snowed under to look at this in a lot of detail currently, but I think what you're saying is, the link between the polkit daemon the polkit authentication agent for GNOME appears to be not working. Is that correct?

Thank you for your kind words, @matt335672! It appears to be an issue with the polkit daemon and polkit authentication agent, although it occurs when remotely accessing via xrdp and does not occur for GNOME Remote Desktop; perhaps it is due to a difference in the way xrdp-initiated GNOME sessions are treated.

I realize GNOME Remote Desktop is just accessing a more local session (is visible from the machine's local screen), so there are likely fundamental differences in the characteristics of the respective GNOME sessions.

[ToeKneeFan]

Also, can you pick a scenario you'd like to look at and we'll step through it.

1. Navigate to Settings.
2. Search for the "Users" setting.
3. Along the top of the window, there should be a prompt "Unlock to Add Users and Change Settings" with an "Unlock" button. Click on this button.
4. An authentication prompt should appear. It does not appear when accessing via xrdp.

[matt335672]

Thanks - I can see that too.

I've got a VM with a privileged user and a non-privileged user. If I use the non-privileged user I get prompted for privileged user credentials on the console, but not in an xrdp session.

I'll figure out what the differences are in both modes and document it here.

[matt335672]

I've enabled logging for polkit by using the instructions on the Arch wiki, i.e.:-

1. Creating the file /etc/polkit-1/rules.d/00-log-access.rules

polkit.addRule(function(action, subject) {
    polkit.log("action=" + action);
    polkit.log("subject=" + subject);
});

2. running this command in a separate window:-

sudo /usr/lib/polkit-1/polkit -r

Logging in on the console, I get the following logged when I enter the users panel:-

action=[Action id='org.gnome.controlcenter.user-accounts.administration']
subject=[Subject pid=8240 user='testuser' groups=testuser,users seat=null session=null system_unit=null local=true active=true]

When I hit the Unlock... button:-

1. I get the authentication dialog.
2. The above logging line is repeated
3. the process /usr/lib/polkit-1/polkit-agent-helper-1 is active. It's a subprocess of gnome-shell

I now run the pk-local debugging script, which adds an override of the 'org.gnome.controlcenter.user-accounts.administration' to auth_admin_keep. I've added my test user to the pk-local group, rebooted and restarted the polkit logging.

Logging on on xrdp, I get the following logged when I enter the Users...

action=[Action id='org.gnome.controlcenter.user-accounts.administration']
subject=[Subject pid=5010 user='testuser' groups=testuser,users,pk-local seat=null session=null system_unit=null local=false active=true]
pk-local: action=[Action id='org.gnome.controlcenter.user-accounts.administration'] user=testuser override=auth_admin_keep

When I hit the Unlock... button, it all appears to be working OK here.

HOWEVER, I do appear to be having some problems switching between the same user over xrdp and the console:-

1. Occasionally loginctl shows a console session stuck in closing state, necessitating a kill-session to recover it.
2. I occasionally get a black screen on my VM console using display :0. If I separately run an xterm on the console, everything appears.

This is perhaps muddying the waters here.

@ToeKneeFan - can you try to reproduce the above with the logging. Please use a different user between console and xrdp session, and make sure after running the script that your user is added to the pk-local group.

[ToeKneeFan]

@matt335672 Sorry to take so long to get back to you!

I created 00-log-access.rules with the indicated content. On my system, /usr/lib/polkit-1/polkit does not exist, so I instead ran polkitd instead:

sudo /usr/lib/polkit-1/polkitd -r

When navigating to the Users panel, the "Unlock" button has disappeared entirely. It is replaced with the banner:

Error: some settings cannot be unlocked

There are no messages in logging upon navigating to the Users panel on my end. However, there are some messages upon initial xrdp login, such as the following

subject=[Subject pid=23091 user='tempuser' groups=sudo,users,pk-local,tempuser seat=null session=null system_unit=null local=false active=false]
action=[Action id='org.freedesktop.accounts.change-own-user-data']

I tried this both with and without the additional 50-pk-local.rules file (created by setup-pk-local) with the same result (no "Unlock" button at all).

Removing 00-log-access.rules and replacing with only 50-pk-local.rules restores the state described in the original post ("Unlock" button reappears, but it does not do anything). (To verify, I used different users for xrdp login and console.)

I am using the current version of xrdp on the apt repository (0.9.24); I assume you may be on a later development version, which may explain some differences in behavior. I can test on a later version/branch if desired.

[matt335672]

Sorry - I meant /usr/lib/polkit-1/polkitd

Also, this is not related to the xrdp version at all - this is pure polkit.

There's probably a difference in the way we're running polkitd. I've realised I'm using a completely separate user.

Can you try the following:-

1. (temporarily) add another user (tempuser2? )with sudo privileges. It does not have to be in the pk-local group
2. Log in as tempuser2 over ssh.
3. Make sure tempuser is completely logged out, i.e. ps -fU tempuser returns no processes.
4. Run sudo /usr/lib/polkit-1/polkitd -r in the tempuser2 session.
5. Log in as tempuser over xrdp and see if we can get some extra logging that way.

Thanks.

[ToeKneeFan]

Thank you, I have run these steps as advised (adding tempuser2 superuser, ssh with tempuser2, ps -fU tempuser had no processes, polkitd -r in tempuser2, xrdp as tempuser) with the same end result. Unfortunately, no "Unlock" button appears, and the message "Error: some settings cannot be unlocked" appears instead. No logging event occurs with opening the Users panel.

At the moment, my only polkit rule in /etc/polkit-1/rules.d/ is 00-log-access.rules, although I have also tried in combination with 50-pk-local.rules. My polkit version is polkitd/noble 124-2ubuntu1.

If it would be helpful, I can try to reproduce on a clean VM.

[matt335672]

There's something going on here I don't understand, that's for sure.

If you're able to start from a clean VM built from an iso, that could be useful. I can then try to reproduce here from the same iso.

[matt335672]

@ToeKneeFan - did you manage to get anywhere with a clean VM?

[ToeKneeFan]

@matt335672 Sorry for the delay; I tried to install to a clean VM, but it appeared to fail/hang, I think due to limited resources (I had other VMs running at the same time). I will try again soon and report back.