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.
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.
While here, embed correct file size in BMP file header.
Fixes: #3102
Sponsored by: Krämer Pferdesport GmbH & Co KG
(cherry picked from commit 4968a34cd62fe740abc612c581e6faa705f12bd1)
The initial implementation of Uinicode input via IBus used a startup delay
of 3 seconds to wait for the daemon to be ready before connecting to it.
This commit introduces a poll-wait loop which can remove the delay
entirely if the daemon is up when chansrv starts the interface.
1) [Regression] If the specified mountpoint is not immediately below an
existing directory, the directory is not created.
2) The message to ask the user to unmount an existing mounted directory
has been moved to the right place.
- 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.
The top level socket directory is now called XRDP_SOCKET_ROOT_PATH.
Below that are user-specific directories referred to with the
XRDP_SOCKET_PATH macro - this name is hard-coded into xorgxrdp and
the audio modules as an environment variable.
XRDP_SOCKET_PATH now looks like $XRDP_SOCKET_ROOT_PATH/<uid>
XRDP_SOCKET_PATH is only writeable by the user, and readable by the user
and the xrdp process.
- added (temporary) suppression of Cppcheck `shiftTooManyBits` false positives in `libxrdp/xrdp_mppc_enc.c`
- added (temporary) suppression of Cppcheck `uninitMemberVar` true positives in `ulalaca/ulalaca.cpp` until fixes land downstream
- fix Cppcheck `nullPointerRedundantCheck` in `sesman/chansrv/clipboard.c`
- fix Cppcheck `syntaxError` in `fontutils/mkfv1.c` because it doesn't see the `freetype/fterrors.h` header / removed astyle workaround
When significant amounts of data is coming from the client in a
fragmented CLIPRDR_DATA_RESPONSE PDU, this code provides a way to
start copying it to a requesting client before it is all read.
The only advantage of this code is to provide a slight speedup
before a paste is visible on the server.
There are significant problems with this code. Notably, it is
very difficult to parse Unicode text coming through this route. Each
UTF-16 character can occupy up to 4 bytes, and a fragmentation
boundary could occur at any point within a UTF-16 character.
Most of the Microsoft RDP documentation describes PDUs on-the-wire.
However, [MS-RDPESC] doesn't do this. It uses DCE IDL to describe the
contents of the PDUs sent over the File System Virtual Channel.
Ideally we'd use an IDL compiler to generate the interfaces in
[MS-RDPESC]. We don't have one though, so all PDUs are read and written
with the low-level streaming routines. It's not clear in the existing
code how IDL is mapped down to this level.
This commit updates the smartcard code with comments which will enable
maintainers to better understand the IDL-to-streaming mappings.
Use the official Windows clipboard format names where appropriate
Replace g_file_format_id with g_file_group_descriptor_format_id
as the latter name is more descriptive of what is described in
[MS-ECLIP]
sesexec.c: In function ‘main’:
sesexec.c:521:1: error: control reaches end of non-void function [-Werror=return-type]
sound.c: In function ‘process_pcm_message’:
sound.c:1123:21: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int i = 0; i < send_silence_times; i++)
^
sound.c:1123:21: note: use option -std=c99 or -std=gnu99 to compile your code
These fixes are in line with our coding standard and have no functional change.
matt335672