Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: When launching a new xrdp session with backend Xvnc on RHEL 9, it opens a TCP port on localhost that may be connected via a vncviewer without requiring a password. Version-Release number of selected component (if applicable): xrdp-0.10.6-1.el9.x86_64 How reproducible: 100% Steps to Reproduce: 1. create a new session via RDP protocal and Xvnc backend 2. ssh -X to the machine it runs on as different user 3. vncviewer :10 Actual results: now you're in full control of the other user's session Expected results: password query window Additional info: Does not occur on my RHEL 8 machines for some reason. I tried setting code=0 in the xrdp.ini, but then the Xvnc does not allow accessing :10 to the window manager that is supposed to start in there. It might have been introduced in 0.10.3 already.
Since 0.10.3, the recommended way is to use Unix domain socket to connect. Have you tried that?
That would be code=1, which apparently is the default on my RHEL 9 and that's what's making authentication optional, because the code launches Xvnc with different options. code=0: Xvnc :11 -auth .Xauthority -geometry 1024x768 -depth 24 -rfbauth /home/myuser/.vnc/sesman_passwd-myuser@myhost:11 -bs -nolisten tcp -localhost -dpi 96 This ones asks for a password (which indeed isn't very secure). However, this is neither the default, nor does it work at all on my RHEL 9. This seems to the be default on RHEL 8, where it works for me. code=1: Xvnc :11 -auth .Xauthority -geometry 1024x768 -depth 24 -rfbunixpath /run/xrdp/2124/xrdp_display_11 -rfbunixmode 432 -SecurityTypes None -bs -nolisten tcp -localhost -dpi 96 This one is listening to port 5910 and accepting vncviewer connections without asking for a password in the first place.
If you have FIPS enabled on RHEL9, VNC password will not work, because it is considered insecure by the cryptographic setup. The machines where this doesn't work, are they FIPS enabled?
# fips-mode-setup --check Installation of FIPS modules is not completed. FIPS mode is disabled. After installing the xrdp on my RHEL 9, it worked out of the box. But since we got so many updates lately and the session manager forgets about running sessions when being restarted, I wanted to create a script to connect to the old session and noticed that there's not fbauth on RHEL 9, so I tried connecting without the password file and, unfortunately, this worked as well. # rpm -q --whatprovides /usr/bin/Xvnc tigervnc-server-minimal-1.15.0-7.el9_8.1.x86_64 Apparently on my RHEL 9, in session.c, line 450 passwd_file is NULL (where on my RHEL 8 it's not), and port is not NULL, so I end up here: 458 else if (port != NULL) 459 { 460 /* UDS connection. Authorization is handled by standard socket 461 * permissions, so we do not need to authorize within the 462 * VNC protocol exchange as well */ 463 char sock_mode[16]; 464 465 /* Convert a standard permissions mask into decimal 466 * for the -rfbunixmode switch argument 467 */ 468 g_snprintf(sock_mode, sizeof(sock_mode), 469 "%d", 0660); /* rw-rw---- */ 470 471 list_add_strdup_multi(params, 472 "-rfbunixpath", port, 473 "-rfbunixmode", sock_mode, 474 "-SecurityTypes", "None", 475 NULL); 476 } And setting SecurityTypes to None is probably what is allowing free access for everyone, while rfbunix* and still allow TCP (and nolisten tcp refers to X11, not VNC).
What are the permissions on the Unix socket used by xrdp when you set code 1? Are you saying that any unprivileged user can use the socket?
# ls -la /run/xrdp/2124/xrdp_display_11 srw-rw---- 1 myuser xrdp 0 May 21 14:34 /run/xrdp/2124/xrdp_display_11 But that's not the point. The point is that the UNIX socket exists in parallel to TCP, not instead of it: # netstat -anp |grep 591 tcp 0 0 127.0.0.1:5913 0.0.0.0:* LISTEN 22331/Xvnc I got to 5913 after some tests, but Xvnc is listening on a TCP socket with SecurityTypes=None. Anyone on localhost is able to connect to it without a password and without requiring the UNIX socket. I can even unlink the UNIX socket from /run (which breaks xrdp) and still use vncviewer to take control over the session.
Yeah, that should definitely not be the case. Only Unix domain socket should be listening. I can have a look at this tomorrow to see whether anything changed recently.
If you can, please attach the config files from /etc/xrdp. It will help with replication of the problem.
If you add these into Xvnc stanza of seaman.ini: param=-rfbport param=-1 And remove: Param=-localhost Does it still listen on local host TCP socket?
The sesman.ini change removed the open TCP port. My sesman.ini was the default shipped with the package. My xrdp.ini without comments, logo, colors and button positions: [Globals] ini_version=1 fork=true port=3389 runtime_user=xrdp runtime_group=xrdp tcp_nodelay=true tcp_keepalive=true security_layer=tls crypt_level=high certificate= key_file= ssl_protocols=TLSv1.2, TLSv1.3 autorun= allow_channels=true allow_multimon=true bitmap_cache=true bitmap_compression=true bulk_compression=true max_bpp=24 new_cursors=true use_fastpath=both ls_width=610 ls_height=450 [Logging] LogFile=xrdp.log LogLevel=INFO EnableSyslog=true [LoggingPerLogger] [Channels] rdpdr=0 rdpsnd=true drdynvc=true cliprdr=1 rail=true xrdpvr=true [Xvnc] name=Xvnc lib=libvnc.so username=ask password=ask port=-1 code=1
FEDORA-EPEL-2026-8d69cba26b (xrdp-0.10.6-2.el9) has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-8d69cba26b
FEDORA-2026-8aeca78af9 (xrdp-0.10.6-2.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-8aeca78af9
FEDORA-2026-6af8517b94 (xrdp-0.10.6-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-6af8517b94
FEDORA-2026-8aeca78af9 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-8aeca78af9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-8aeca78af9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2026-8d69cba26b has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-8d69cba26b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2026-cf191f562d has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-cf191f562d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-9a3a98bc24 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-9a3a98bc24` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-9a3a98bc24 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-6af8517b94 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-6af8517b94` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-6af8517b94 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2026-8d69cba26b (xrdp-0.10.6-2.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-9a3a98bc24 (xrdp-0.10.6-2.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2026-cf191f562d (xrdp-0.10.6-2.el8) has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-8aeca78af9 (xrdp-0.10.6-2.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.