Made session allocation policies more readable and maintainable.
The 'C' policy which was confusing before has been replaced with the
'Separate' keyword. This is a public interface change, but is unlikely
to affect many users.
The logging in session_get_bydata() is substantially improved, making
it far easier to spot why sessions are getting matched or not matched.
The connected client is currently described in two places in
the xrdp_client_info structure:-
1) In the connection_description field. This was introduced as
field client_ip by commit d797b2cf49
for xrdp v0.6.0
2) In the client_addr and client_port fields introduced by commit
25369460a1 for xrdp v0.8.0
This commit unifies these two sets of fields into a single
set of fields describing the connection IP and port (for
AF_INET/AF_INET6 connections only) and a connection description
for all connection types.
The code in os_calls to provide client logging has been simplified
somewhat which should make it easier to add new connection types (e.g.
AF_VSOCK).
The old connection_description field used to be passed to sesman to
inform sesman of the IP address of the client, and also to provide
a string for 'C' field session policy matching. 'C' field session policy
matching does not actually need this string (see #2239), and so now only
the IP field is passed to sesman.
Windows 10 RDS is quite relaxed about missing channel join PDUs,
whereas we have to adhere quite tightly to the specification to
make sure we get a TLS "Client hello" where appropriate. This makes
us incompatible with older RDP clients. For example, the Wyse sx0
thin client does not send a channel join PDU for the user channel.
Older, non-TLS versions of xrdp supported these devices.
This commit re-implements the xrdp v0.6.1 behaviour for non-TLS
connections only, allowing system administrators to use these devices
on trusted networks. These devices are in any case too old to
establish a modern TLS connection.
The Windows 10 RDS sets the user channel ID to be one more than the
ID of the last allocated static virtual channel. Currently we set it to
1002 (0x03ea) which is allocated to the server channel. This change
makes xrdp emulate RDS more closely.
The code in xrdp_mm.c to connect to chansrv over a TCP socket has
been removed, with the move to UDS. This PR simply removes the
chansrv TCP listening code. Without doing this, some configurations
result in a failure of xrdp to connect to chansrv.
The TCP socket implementation of sesman has a number of limitations,
namely that it is affected by firewalls, and also that determining the
user on the other end requires a full authentication process.
The advantage of the TCP socket is that sesman and xrdp can be run on
separate machines. This is however not supported by the xorgxrdp
backend (shared memory), and is insecure, in that passwords are sent
in-the-clear, and the connection is susceptible to MitM attacks. This
architecture has been deprecated in release notes since xrdp v0.9.17,
and although it will continue to be supported in any further releases
in the x0.9.x series, it will not be supported in the next major
version.
When sesman used a standard TCP socket, we were guaranteed only one copy
of sesman could run on on address, as standard TCP listening rules
enforced this. This isn't the case with Unix Domain sockets. This
module implements a locking mechanism for a UDS which emulates the
standard TCP socket behaviour.
This is required for PAM systems that depend on group membership being
available during PAM processing. This is used by pam_group on FreeBSD
and pam_group on Linux-PAM, although the functionality of both is
different.
There are a number of ways the existing transport connect logic in
trans_connect could be improved for POSIX compatibility, and also
slightly tidied up:-
1) The same socket is re-used for multiple connect attempts following
failure which isn't behaviour defined by POSIX.1-2017 (although it
works on Linux).
2) An asynchronous connect is started, and then after a short
delay connect() is called again on the same socket. POSIX.1-2017
is clear that in this situation EALREADY is returned before the
connection is established, but is silent on the behaviour expected
when the connection is established. Returning success is an option,
but so is returning EISCONN. The current code assumes the connect()
call will succeed.
3) The code contains two virtually identical, quite complex loops for
TCP and UNIX sockets, differing only in the calls to create a socket
and connect it.
4) trans_connect() contains looping and retry logic, but this isn't
seen as sufficient by the chansrv connect code in xrdp/xrdp_mm.c and
the Xorg connect code in xup/xup.c. Both of these implement their own
looping and retry logic on top of the logic in trans_connect(),
resulting in slightly unpredictable behaviour with regard to
timeouts.
5) A socket number can technically be zero, but in a couple of places
this isn't allowed for.
This PR attempts to correct the implementation of trans_connect(),
and also to simplify the areas it is called from.
As part of the PR, the signature of the server_is_term member of the
xrdp module interface is changed to match the signature expected by the
is_term member of a struct trans. This allows for trans_connect()
in xrdp modules to directly access g_is_term() within the main xrdp
executable. At the moment this functionality is only used by the xup
module.
- Eliminate duplicaiton for display_size_description
- monitorCount needs to be uint32_t
- width/height -> session_width/session_height
- Update CLIENT_INFO_CURRENT_VERSION
- Also some misc unit test updates.
- Minor log updates.
There are two places where monitor descriptions are passed through the
RDP protocol:
- TS_UD_CS_MONITOR ([MS-RDPBCGR] 2.2.1.3.6 Client Monitor Data)
- DISPLAYCONTROL_PDU_TYPE_MONITOR_LAYOUT ([MS-RDPEDISP] 2.2.2.2)
The processing logic for both of them is similar enough that they should be unified.
Also update to define the constants for the maximum and minimum desktop width/height for monitors and total area.
Also a large number of clarifications for the constants and protocol
requirements.
Note that this is also the first step to making resizing work with the extension GFX channel as well as an important
foundational step to enable HiDPI compatibility.
Also some misc logging updates.
