Ignore version. Bug exists in every version.

pkexec can't handle sessions created by Xrdp. It clearly wants something from the session manager
that the session manager cannot provide. On the other hand, whatever it wants from the session manager,
it does not need.

Tried to configure a new policy kyt file in /usr/share/polkit-1/actions; discovered that it doesn't
matter what the file contains, nothing will run because pkexec can't find the currently logged-in session.
(This is a server. The only kinds of GUI logged in sessions are Xrdp and ssh -X.)

Tried setting up gtksu but it doesn't exist anymore.

Grumbled and rot out the C compiler and wrote a completely stupid suid-target-user binary that copies
.Xauthority and sets up environment variables and runs the target binary.

Apologies--I am having to re-report this bug from a different system as reportbug from the system with
the problem went to the bitbucket. I removed the obviously incorrect information below.

Are you able to run something like 'pkexec id' from a ssh login to the
same system, and escalate privileges to root that way? If that works,
and the same command in a shell on an Xrdp connection doesn't, then that
isolates the problem to be something specific to Xrdp.

What polkit requires is that the privileged process into which you log in
(for example sshd or gdm or login) registers with systemd-logind (or
elogind, if you're using that) via a PAM stack that runs pam_systemd
(or pam_elogind), before forking a child process that drops privileges
to run as you. For example, for sshd this is normally done by
/etc/pam.d/sshd containing "@include common-session", and
/etc/pam.d/common-session containing "session optional pam_systemd.so".

I don't know how Xrdp works, so I don't know which process ought to be
responsible for this.

If you use systemd, systemd-cgls will show you how the OS thinks the
various processes and cgroups fit together. On a typical desktop/laptop
system with gdm/xdm/sddm/whatever or with getty/login on the console,
or on a server with ssh logins, it will go something like this:

-.slice
├─user.slice
│ └─user-1000.slice (or whatever your numeric uid is)
│   ├─user@1000.service
│   │ └─... per-user services shared by all login sessions, like gpg-agent ...
│   ├─session-c1.scope
│   │ └─... the processes associated with a getty/login session on tty6 ...
│   ├─session-1.scope
│   │ └─... the processes associated with a ssh login session ...
│   └─session-2.scope
│     └─... the processes associated with a gdm login session ...
├─init.scope
│ └─1 /sbin/init splash
└─system.slice
  ├─... OS services like polkit.service itself ...

If the shell from which you run pkexec appears below user-1000.slice, then
polkitd should be able to recognise it as part of the session (and if it
can't, we would need more debug information from polkitd and/or pkexec to
figure out why not).

If it appears below system.slice, then something that Xrdp is doing is
incompatible with polkitd's (and systemd-logind's, and many other services')
model of what is part of a session and what isn't.

loginctl(1) might also provide useful information (for either systemd-logind
or elogind).

On a server-class, mostly-text-mode system it would be more typical to
use sudo, or configure public key authentication to be able to ssh in
as root without a password. (By default, Debian's sshd configuration
will allow root logins using a key listed in /root/.ssh/authorized_keys,
but will not allow root logins using password authentication, because
password authentication is much more susceptible to attacks.)

    smcv