remove not used chansrv <-> xrdp messages
move static channel disable control into libxrdp
remove some blocking read, write chansrv calls
add drdynvc calls to libxrdp
add drdynvc calls to chansrv
channel cleanup
Configured ls_label_width and ls_input_width currently only apply to the combo l
abel and dropdown. Other labels and inputs (username, password, port, ...) use hardcoded defaults.
Also had to change the default label width; for the previous value of 60, "username" ends up just a few pixels too wide.
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.
