THe function xrdp_sec_in_mcs_data() parses data within the
TS_UD_CS_CORE struct which could just as easily be parsed
when xrdp_sec_process_mcs_data_CS_CORE() is called.
Currently the contents of the MSC Connect Initial PDU are stored within
the client_mcs_data member of the xrdp_sec struct. This stream is parsed
once by xrdp_sec_process_mcs_data() and then separately by
xrdp_sec_in_mcs_data(). There is no reason not to perform the parse in
a single pass through the stream.
This commit folds the functionality in xrdp_sec_in_mcs_data() into
xrdp_sec_process_mcs_data_CS_CORE() and removes xrdp_sec_in_mcs_data()
We always now indicate we support skipping channel joins. If the client
indicates this too, expect no channel join requests from the client.
If we do get some, process them anyway.
The existing code contains separate TLS and non-TLS code paths for
hadling channel join PDUs. This was introduced in
8fdc1ba216 and was based on a
misunderstanding of where in the connection sequence the TLS client hello
is processed (if a TLS connection is negotiated). The assumption was
the TLS client hello is received after the channel join PDUs. However,
it is actually received immediately after the X.224 Connection Confirm
PDU some time before channel join requests are processed.
Consequently, there is no reason not to adopt a single code path for
handling channel joins.
xrdp_load_keyboard_layout() is used exclusively by the xup module to
work out the parameters to pass to xorgxrdp for XKB. This function
does not need to be called locally from the SEC module.
This commit moves the function to xrdp/lang.c and renames it as
xrdp_init_xkb_layout(). The module interface is modified so that xup can
call this function. Other modules do not need to call it.
Replace definitions in ms-rdpbcgr.h marked as TODO with the
names defined in [MS-RDPBCGR]
Some other simplifications around the fake Unicode event processing
have also been made.
This commit changes the license response PDU to be constructed rather
than simply being contained as a binary blob.
Some constants in common/ms-rdpbcgr.h are renamed with the values
from the specification.
Replaces the existing licensing exchange with a single PDU
saying the user will not issue a license.
This is necessary for clients on FIPS-compliant systems, as these
are unable to decode the licensing exchange packets, due to outdated
cyphers.
If the setting require_credentials is true, there should be no way
for the user to get to a login screen.
This commit makes the following changes if this flag is active:-
- Makes the checks around TS_INFO_PACKET more explicit.
- Closes the connection if the first login attempt fails.
- xrdp is not now built with XRDP_IBUS to allow other input
methods to be more easily supported.
- chansrv is only aked to start an input method if the client
supports it.
- chansrv sends a status report back to xrdp when asked to start
and input method.
- ./configure without --enable-ibus now works.
This commit moves the '[Channels]' parsing code for xrdp.ini
from xrdp_wm_init() to an earlier location in xrdp_wm_create().
libxrdp can now check that drdynvc is not disabled before starting it,
and xrdp_wm can disable GFX if virtual channels are not available.
The responsibility for starting the drdynvc channel is moved out of
libxrdp into the application. This will make it easier to allow the
application to check the channel is enabled before starting it.
From [MS-RCPBCGR] 3.3.5.12.1:-
> ...The contents of this PDU SHOULD NOT be compressed.
>
> This PDU MUST NOT be sent to a client that has not indicated support for
> it by setting the RNS_UD_CS_SUPPORT_MONITOR_LAYOUT_PDU flag (0x0040)
> in the earlyCapabilityFlags field of the Client Core Data (section
> 2.2.1.3.2).
Also, 2.2.12.1 specifies the source channel must be zero.
In testing, a compressed monitor layout PDU causes mstsc.exe
to exit with a protocol error.
This fixes some monitor hotplug issues with non-GFX codepaths.
1) The server_version_message() was working on an out-of-date
copy of the client_info. As a result, the X server and the
window manager did not agree on the number of windows
2) As a result of 1), a memory leak was found in the VNC module.
* Store EGFX state before entering resize state machine
At present the EGFX state is destroyed by states WMRZ_EGFX_DELETE_SURFACE
through WRMZ_EGFX_DELETE. This means that at WMRZ_EGFX_INITIALIZE we
cannot distinguish between EGFX not being ever used, and EGFX
having been torn down. Consequently, when running non-GFX, we don't
correctly recover the session.
* Allow multiple reasons for suppress_output
Replaces the single boolean for suppress_output with
a bitmask, to allow output to be suppressed for
more than one reason
* Disable output during resize
* Add states to dynamic resize
Adds states to the dynamic resize state machine so we wait for a
Deactivation-Reactivation sequence to finish before sending pointer
updates, etc.
* suppress module output during the dynamic resize
* Add support for dynamic resize to VNC backend
xrdp_mm needs to be informed when a resize has been performed so that
the resize stte machine can be updsate.
Since v0.9.9, xrdp has assumed that the "drdynvc" static virtual
channel is available for its exclusive use. With GFX support, it
is necessary to codify this to prevent this sequence of operations:-
- NeutrinoRDP target sends DVC Capabilities Request PDU
- target responds wih DVC Capabilities Response PDU
- xrdp processes this, starting the GFX virtual channel again
In the future, if NeutrinoRDP requires access to virtual channels,
data may somehow need to be passed through to the target while being
parsed and handled appropriately within xrdp.
mstsc.exe indicates it supports GFX in the early capability flags, even
if it not able to support 32 BPP. This results in a session failure
if a RDPGFX_CAPS_CONFIRM_PDU is sent on the EGFX virtual channel.
- Mostly base functions and utilities necessary to enable RFX
Progressive
- Add more EGFX work & mode flags.
- Update encoder.
- Does not yet include caps determination to enable RFX progressive
(yet).
- Update protocol constants
Some clients appears to be sending cbClientAddress and/or cbClientDir
as 0 in the TS_EXTENDED_INFO_PACKET. This appears to be at odds with
[MS-RDPBCGR] which requires mandatory terminators for these fields.
Rename g_file_open() to g_file_open_rw(), and add a new g_file_open_ro()
call that wraps the common g_file_open_ex(file, 1, 0, 0, 0) idiom. This
will make the file access mode more explicit in the code.
Change all calls to g_file_open() to the _ro() or _rw() variant as
appropriate, and replace g_file_open_ex(file, 1, 0, 0, 0) with the _ro()
call.
Lastly, add tests for the two new calls to test_os_calls.c (code
courteously provided by matt335672).
Although there is nothing in the specification to prevent automatic
logons with empty passwords, this is not a secure default.
The autologon flag INFO_AUTOLOGON ([MS-RDPBCGR] 2.2.1.11.1.1) is now
ignored for empty passwords.
To implement a scalable login screen, we need to be able to ascertain
the DPI of the connected primary monitor.
At present, in a multi-monitor situation, this information is available in
the struct display_size_description, which can be searched for the primary
monitor. This is only the case however if the Display Control Channel
Extension is in use ([MS-RDPEDISP]), and a DISPLAYCONTROL_MONITOR_LAYOUT
has been received.
This PR retrieves physical monitor size information from the following
two additional places.
1) The TS_UD_CS_CORE PDU. Physical size information is optionally
included in this PDU for single-screen configurations.
2) The TS_UD_CS_MONITOR_EX PDU. This includes physical size
information for multiple-screen configurations.
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.
matt335672