If you run xrdp with a Unix Domain Socket (UDS) for the port specified in
/etc/xrdp/xrdp.ini then the first connection succeeds but subsequent
connections fail. In fact the UDS is deleted from the filesystem as soon
as the first connection is established.
Test case:
1. Edit /etc/xrdp/xrdp.ini to set "port=/var/run/xrdp-local.socket".
2. Restart xrdp.
3. Run the following. When rdesktop starts up and the logon dialog is
displayed, press "Cancel".
sudo socat TCP-LISTEN:12345 UNIX-CONNECT:/var/run/xrdp-local.socket &
rdesktop localhost:12345
4. Run the following:
sudo socat TCP-LISTEN:12346 UNIX-CONNECT:/var/run/xrdp-local.socket &
rdesktop localhost:12346
Expected behaviour: rdesktop starts up and displays the logon dialog.
Observed behaviour: rdesktop exits with "ERROR: Connection closed" and
socat exits with "No such file or directory.
This is because in the child process after forking, xrdp_listen_fork()
calls trans_delete() which deletes the UDS. Simply commenting out the
g_file_delete() and g_free() fixes this, but that isn't a proper solution
because trans_delete() is called from elsewhere where the UDS might no
longer be wanted.
Fix by adding a function trans_delete_from_child() that frees and clears
listen_filename before calling trans_delete(), and call the new function
from xrdp_listen_fork().
(Workaround: set "fork=false" in /etc/xrdp/xrdp.ini, because
trans_delete() is then not called.)
In most cases, checking fd > 0 is not valid. open(2) returns -1 on
error, 0 on stdin, 1 on stdout, 2 on stderr, >2 . The border should be
between -1 and 0. Additionally, between 2 and 3.
Pointed out by: #919
The log is always logged when clients are disconnecting even though
nothing unusual is happening. This scares users too much. Actually,
some users created a issue on GitHub with the following log. It will
lose focus from the real error.
> [ERROR] Listening socket is in wrong state, terminating listener
such as prefill username and password:
username=ask{base64}YmFzZTY0
username={base64}YmFzZTY0
password=ask{base64}YmFzZTs2NCFwYXNzd29yZCM=
password={base64}YmFzZTs2NCFwYXNzd29yZCM=
';', '#', '!' means comment in .ini files. If prefill username or
password contains such symbols, these can be provided base64 encoded.
If you run xrdp with a Unix Domain Socket (UDS) for the port specified in
/etc/xrdp/xrdp.ini then only root can connect to it.
Test case:
1. Edit /etc/xrdp/xrdp.ini to set "port=/var/run/xrdp-local.socket".
2. Restart xrdp.
3. Run the following, as a non-root user.
socat TCP-LISTEN:12345 UNIX-CONNECT:/var/run/xrdp-local.socket &
rdesktop localhost:12345
Expected behaviour: rdesktop starts up and displays the logon dialog.
Observed behaviour: rdesktop exits with "ERROR: Connection closed" and
socat exits with "Permission denied". (But it suceeds if root runs
socat.)
UDS files are created by trans_listen_address() and given permissions
0660, so only root can connect to it. In this case, for the RDP client
connection, it it fine for any user to connect so it should be given
permissions 0666.
Note that this is only relevant when the port in /etc/xrdp/xrdp.ini has
been set to create a UDS instead of a TCP socket. When a TCP port is
created any user (including remote users, unless the loopback interface
is used) can connect so this is not less secure.
The UK/GB keyboard doesn't work properly connecting to xrdp with xorgxrdp.
It does work when connecting to xrdp with x11vnc, however.
This is because the layout is not declared in xrdp_keyboard.ini. It needs
to be called "gb" not "uk". (There are other layouts that have
km-nnnn.ini files that aren't declared in xrdp_keyboard.ini, so they might
have the same bug, but I haven't tested that. This is analagous to the
commits for the "ch" and "pl" layouts.)
Test case:
1. Use a PC with the UK/GB keyboard layout.
2. Create /etc/xrdp/startwm.sh as follows:
#!/bin/sh
export LANG=en_GB.UTF-8
export MDM_LANG=en_GB.UTF-8
export XTERM_LOCALE=en_GB.UTF-8
xterm
exit 0
3. Connect using rdesktop to localhost (from a session where the same
environment variables are defined).
4. Test layout-specific keys such as:
\ (backslash)
| (bar)
# (numbersign)
~ (asciitilde)
£ (sterling: Shift-3)
€ (EuroSign: AltGr-4)
These keys should produce the appropriate symbol but they don't. With
the change in this commit the keys produce the correct symbol.
As some clinents (AFAIK Windows 10) always send domain name, the backend
module is not selected properly. This causes the default usage with
Windows 10 fails with 'xrdp_wm_log_msg: Section "XXX" not configured'.
Koichiro IWAO
Jay Sorg
Ben Cohen
fbourqui
Vraiment
rkantos
Justin Terry (VM)
Soedarsono
Felix Zhang
Oscar Salvador
cocoon
Pavel Roskin