When a connection is made to a system with the client numlock pressed, a
TS_SYNC_EVENT is sent before the module is loaded. This TS_SYNC_EVENT
correctly contains the NumLock status as 'pressed'. The event is, however,
discarded as the module isn't loaded.
When the module is loaded, a TS_SYNC_EVENT is not sent again unless
client focus is removed from the xrdp window and re-applied. As a
result, the NumLock state is incorrect unless this is done.
This commit stores the last TS_SYNC_EVENT sent before a module is
loaded. When the module is loaded, the sync state can be correctly
communicated to the module.
This commit allows a keycode_set to be specified as a module parameter
in xrdp.ini. This has the following effects:-
1) xrdp loads the specified keycode set for mapping RDP scancodes to
X11 keycodes. These are then passed to xorgxrdp as part of key press/
key release events.
2) The name of the XKB rules which use the specified keycode set are
passed to xorgxrdp so that XKB can be configured with rules which
match the chosen keycodes.
The effect is to remove all keycode set dependencies from xorgxrdp.
Normally evdev rules and evdev keycodes will be used but base rules and
base keycodes can be used instead for applications that require them.
Also, any systems which do not ship the evdev rules can be made to
work with base rules.
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.
The Brazilian ABNT2 Keyboard layout contains a keypad
decimal key which doesn't exist on other keypads:-
https://www.kbdlayout.info/kbdbr/virtualkeys
This key is curently mapped in xorgxrdp to keycode 134 (basic mapping),
but isn't present in the scancode map. It needs to be added so that it
is available to VNC sessions and will be mapped for xorgxrdp when we
move to evdev keycode mappings.
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.
The mapping from scancodes to the indexes used in xrdp_keymap
is not well designed and contains an implicit dependency on
keycode values.
This mapping is alse slightly different from the index used for
the 'keys' map in the xrdp_wm structure.
This commit introduces support for mapping scancodes directly
to 'scancode indexes' suitable for indexing into both structures.
Some renaming is also done; [MS-RDPBCGR] uses the terms scancode
and keyCode interchangeably. An effort is made to use key_code for a
raw value from a TS_KEYBOARD_EVENT, and scancode for a value which is
produced by the scancode module.
When used with a FreeRDP client on Linux, a file copy operation from
the clipboard detects end-of-file by a read returning 0 bytes. This is
currently marked as an error.
It is assumed that mstsc.exe detects end-of-file in another way, which
is why this has not been found before.
The routine clipboard_get_files() parses a potentially long string,
and copies portions of it into a temporary buffer. This buffer is then
passed to clipboard_get_file() as pointer + length;
The buffer is inadequately sized for very long filenames which may
approach XFS_MAXFILENAMELEN in length. This can cause chansrv to fail
when the user copies such filenames.
It turns out the buffer is unnecessary, as the filenames can be
passed directly into clipboard_get_file() from the source string,
using pointer + length. This avoids the length limitation entirely.
The limit of 256 characters for clipboard files is limiting for
many Asian locales, particularly as '%xx' notation is used to
communicate bytes with bit 7 set.
Replace the 256 byte buffer used for names in the XFS filesystem with a
dynamically allocated buffer.
The define XFS_MAXFILENAMELEN which used to be 255 has been retained,
but bumped to 1023. This value is no longer used for long-lived
allocations, but is used in chansrv_fuse.c for maintaining state
information for in-fligh I/O requests.
These config files are intended to be substituted during the build
process. The substituted .ini files should not be included in release
tarballs.
Fixes: #3187
(cherry picked from commit 19bacc6e49)
The state buffers used by the following structs in chansrv_fuse.c
are one byte too small for filenames of length XFS_MAXFILENAMELEN:-
- struct state_lookup
- struct state_create
- struct state_rename
In practice, there is no runtime danger, as XFS_MAXFILENAMELEN is 255,
and these buffers will be followed by non-byte aligned data. Nevertheless
this should be fixed to prevent problems if the value is changed.
struct pre_session_item has an entry for the start_ip_addr which is not
being filled in. This is not normally needed, as the IP address of the
session is passed into the session another way, but it is needed if the
session selection Policy contains the 'I' selector.
Files included in distribution tarball must always be enumerated,
not be enumerated conditionally.
Resolves: #3149
(cherry picked from commit e83dcc52eb)
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.
The unprivileged user needs to be able to read the certificate and
key files to offer TLS, but should not be able to write to then.
This commit checks the TLS files are read-only, rather than
simply readable
If xrdp is running with dropped privileges it won't be able to delete
the PID file it's created. Places where xrdp is stopped need to cater
for this.
It's prefereable to do this than make the PID file writeable by xrdp
with dropped privileges, as this can still lead to DoS attacks if an
attacker manages to modify the PID file from a compromised xrdp
process.
matt335672