Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in

[Markus Koschany]

Hello,

the new Bullseye version of xrdp is identical to the version in Bookworm. Thus
the underlying problem is probably more complex and I don't suspect that
something is wrong with xrdp itself but more likely with a configuration option
or related software packages which do something different than in Bookworm.

I have tried to reproduce the problem on Bullseye with Gnome 3 installed. The
problem here is that gnome-remote-desktop appears to interfere with xrdp, so
I'm not totally sure what is caused by Gnome and what might be a bug in xrdp.
Then I restarted the session with Gnome in Xorg mode and a remote connection to
the xrdp server succeeded. However I got a black background instead of the
normal wallpaper I have. Applications were shown correctly though.

I definitely need more information about your setup or xrdp in general to debug
this issue. Possible reasons for the behavior may be:

1. TLS / connection problem ? Did you do "adduser xrdp ssl-cert" ? Maybe a new
TLS configuration option in 0.9.21.1?

2. graphic drivers ? I read that hardware accelerated drivers may cause such
problems. Maybe try to disable them and use software rendering only?
LIBGL_ALWAYS_SOFTWARE = true

Please also upload the following log files:

/var/log/xrdp-sesman.log
/var/log/xrdp.log
~/.xsession-errors

and

journalctl -S -2m

or something similar may provide more information about error messages, etc.

~/.xorgxrdp.10.log seems to belong to xorgxrdp. The package is only recommended
but I wonder if the problem is potentially caused by it. xrdp is a build-
dependency which suggests it might need a rebuild? But on the other hand then
recommending the package would be wrong and it should be added to Depends.
Someone else would have stumbled upon this sooner I guess.

Regards,

Markus

[Thorsten Glaser]

tags 1052197 + patch
thanks

On Wed, 20 Sep 2023, Thorsten Glaser wrote:

>I’ll try binNMU’ing (locally) xorgxrdp, and if that doesn’t help,

OK, that helped! It went fast.

Installing the binNMU’d package xorgxrdp_0.2.12-1+b0.1_amd64.deb
(and killing all /usr/lib/xorg/Xorg processes spawned from xrdp,
visible by using :10 and higher as DISPLAY numbers) fixed this.

So please ask someone (SRM, I believe) to schedule binNMUs of
xorgxrdp for all oldstable architectures in oldstable.

Thanks!

bye,
//mirabilos
--
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

[Thorsten Glaser]

On Thu, 21 Sep 2023, Markus Koschany wrote:

>dependency problem between xrdp and xorgxrdp. If you claim that without a
>rebuild of xorgxrdp a new upstream version of xrdp would be broken, then this
>is a strong indication that xorgxrdp should be more than a recommendation in
>Debian terms:

No, just some kind of ABI thing, but I doubt xrdp upstream already
even guarantees stable ABIs for 0.x releases.

Probably something like the X server itself or Perl, where xrdp
Provides xrdp-abi (= 0.9.21) and xorgxrdp Depends xrdp-abi (= 0.9.12)
and therefore automatically needs a binNMU to get the newer one *and*
lockstep upgrades are enforced by that.

>From the Debian Policy "Declaring relationships between packages"
>
>"The Depends field should be used if the depended-on package is required for
>the depending package to provide a significant amount of functionality."

Yes. Not applicable here, xrdp does not need xorgxrdp to provide
a significant part of use cases. xorgxrdp is a plugin that can be
added to provide the third significant use case out of three, AIUI.

bye,
//mirabilos
--
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)