password input pop-up window is not working in some cases.

[HubKing]

By that I mean something like this screenshot: https://devanswers.co/wp-content/uploads/2021/01/authentication-is-required-to-create-a-color-managed-device.png

I have tested multiple distributions and multiple desktop environments with XRDP and all of them had issues with that sort of dialogue. In some cases, the dialogue does not appear at all (thus the app fails), and in some cases, it appears for some apps, but not for other apps. For example, for Ubuntu 22.04, that dialogue shows up for the colour profile creation, but not for other things like Settings -> Users -> Unlock. Pressing that button should show that password dialogue, but in an XRDP session, it shows nothing.

1. Is this a bug of XRDP?
2. If not, is this an inherent limitation of Linux that cannot be fixed by XRDP developers?
3. If not, is this misconfiguration of Linux or XRDP? If so, could you add a Wiki page to explain the correct set-up?
4. If not, in what distribution + desktop environment does the password window always work just like a local session?

[metalefty]

Editied title 'cause it's not sudo.

[matt335672]

@HubKing - you'll need to look into polkit and how it works.

In short, a remote session does not have the privileges a local session has. This is for good reasons - depending on your use-case(s) you may not want a remote user to have the same control over the system a local user does. On a shared system for example, remote users should not be installing updates or shutting down the system. On a single user system, you probably do want to allow that.

xrdp is treated as a remote session by polkit. We have no control over that, or the default local policies a particular distro may choose to install.

A wiki page would be great in theory, but not only is it a lot or work to create, but more importantly for us, it will also be a lot of work to maintain because of the level it will need to be pitched at. At the moment we simply don't have the effort available. I hope the rest of this post will illustrate that.

I'll BRIEFLY take your example which is a dialog containing the text "Authentication is required to create a color managed device". I'm not explaining this in a lot of detail, but anyone knowing a bit about polkit should be able to follow this.

First thing is to identify the distribution. I don't have Ubuntu 22.04 handy right now, but I've got 20.04, where the same happens. I'll use that as you say you've tried a few. The distribution is important as this determines:-

• the polkit version
• the names given to the 'polkit actions'.
• how we look into polkit logging

polkit itself comes in two flavours - the 0.105 version and earlier, and later versions. Many distros, including Debian and its derivatives, have chosen to stick with 0.105 and earlier because it is (arguably) more secure by not using Javascript to define actions.

On my Ubuntu 20.04 machine I log in, get the "Authentication is required to create a color managed device" and hit cancel.

I can now look in /var/log/auth.log, where I see the following message which identifies the action which was not authenticated:-

Operator of unix-session:c7 FAILED to authenticate to gain authorization for action org.freedesktop.color-manager.create-device for system-bus-name::1.402 [/usr/libexec/gsd-color] (owned by unix-user:testuser)

So the polkit action is org.freedesktop.color-manager.create-device.

I can query how polkit defines the action with:-

$ pkaction --verbose --action-id  org.freedesktop.color-manager.create-device
org.freedesktop.color-manager.create-device:
  description:       Create a color managed device
  message:           Authentication is required to create a color managed device
  vendor:            System Color Manager
  vendor_url:        https://www.freedesktop.org/projects/system-color-manager/
  icon:              application-vnd.iccprofile
  implicit any:      auth_admin
  implicit inactive: no
  implicit active:   yes
  annotation:        org.freedesktop.policykit.owner -> unix-user:colord

The implicit_active line relates to local sessions (i.e. on the console). yes means the action is authorized, so we never see that pop-up on the console.

The implicit_any line relates to remote sessions (i.e. xrdp). auth_admin means an admin needs to authentication to allow the action, hence the pop-up.

We can override this prompt by creating a .pkla file for polkit 0.105. I'll call it /etc/polkit-1/localauthority.conf.d/10-remote-color-profile.conf and it contains the following:-

[Configuration]
Action=org.freedesktop.color-manager.create-device
ResultAny=yes

After restarting the polkit daemon with sudo systemctl restart polkit I can now log in without the prompt.

That's a really simple example, but I hope it gives you an idea of what polkit is doing and why.

[HubKing]

Thanks, but I had already disabled the login colour profile password dialogue (it seemed to be an "infamous" issue, so I could easily find web pages that listed solutions for it) by editing the polkit policy file. If making an RDP session exactly like a local session is very complicated or impossible, I think I will just give up and use the root account to log in to RDP, but I am not really sure how much security the OS can achieve by inconsistently allowing that password dialogue in an RDP session. I mean, it does not completely disable the password dialogue for all apps, but only for certain apps and if I were trying to use the password dialogue in an RDP window, it means that the user is already a "sodoer", which means, theoretically, I could do any harmful thing in that RDP session, without that password dialogue, by opening a terminal and do things like `sudo rm -rf /'.

[matt335672]

A couple of extra thoughts for you:-

• You need to be careful with some of the solutions to the colour profile issue. We've noted that if you try to use a solution not suited to your operating system, it can cause polkit to fail in a way that makes it completely ineffective. Don't use anything which uses polkit.AddRule on a Ubuntu system - it may not be doing what you think it's doing.
• It's completely up to you how you log in to your system, and without knowing about your particular circumstances I'm not going to say you shouldn't log in as root. However, I'm not convinced that logging in as root will solve all your problems though - you may well find things that are simply not allowed for remote sessions.
• You mention 22.04. Depending on your use cases, you might find the GNOME desktop sharing over RDP [ubuntuhandbook.org] a better match for what you're trying to do. Its usages overlap with xrdp, but because you're already logged in to the console when you use it, it's a lot less complicated - or it seems to be (I haven't tried it yet).

[HubKing]

Gnome 42's in-built RDP is useless for my use case, because I am trying to manage a headless server (I use SSH, but for certain things, graphical management is easier). Gnome's RDP has no login capability. It only works when the account has already been logged into Gnome desktop locally, and its RDP screen is identical to the local screen. So, it basically works like VNC, but without the login capability.

Frankly, I am not sure why Gnome developers thought it would be a good idea to ship with that kind of RDP. That sort of limitation makes RDP almost useless. Even Window's RDP allows login (although it makes the local session end). I can think of very limited use cases for Gnome's RDP, like some novice user wants to show his desktop to his remote knowledgeable friend to solve a problem.

[matt335672]

Well, that's useful feedback for others thinking of going down that route. Thanks for adding it.