* Initialise inode table in `xfuse_create_share()` if necessary
* Add guard to `xfuse_init_xrdp_fs()` to prevent double initialisation of the inode table
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.
Test case: On a system running xrdp with no sessions running run:
xrdp-sesadmin -u=<user> -p=<password> -c=list
Expected result: "No sessions." (ignoring debug output)
Observed result: "Error getting session list."
In the SCP_SERVER_STATE_MNG_LISTREQ case in scp_v1_mng_process() if
there are no sessions it ends the scp session, which causes an error in
the client. In commit 0017081d the client was changed to report errors,
giving the result above.
Fix by calling scp_v1s_mng_list_sessions() from scp_v1_mng_process()
even when there are no sessions, and if so sending a packet with a count
of zero so that the client gets what it expects.
as it was undocumented and few people know reconnectwm.sh is executed on
client reconnect. The behaviour of startwm.sh / reconnectwm.sh should
be documented. This is a first step of documenting them.
We shouldn't assume that xrdp daemon is running under root privilege.
In many cases, root privilege is not really needed for xrdp daemon.
xrdp may fail to load certificate/privkey due to lack of permissions
when running under user privilege. Checking existence of files is not
enough and xrdp should output user-friendly log in such case.
Reported by Debian user in bug 856436 [1].
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856436
matt335672
Koichiro IWAO
Ben Cohen
Ian Geiser
Jay Sorg