57609d4aa7 introduced an issue where
the numCapabilities field in the DR_CORE_CAPABILITY_REQ PDU
was incorrect unless --enable-smartcard was specified.
This commit also improves the logic around handling clients who
advertise a smartcard even if we do not support it.
The smartcard code contains a number of security vulnerabilities and
does not work at the moment.
The code has been left in the source tree, but moved behind an
'--enable-smartcard' configure flag which is clearly marked as not
for production use.
As far as possible, use of the X11 display number is kept to
X11-specific routines. This is to make it easier to restructure
the code to add non-X11 display support.
Functions are added to xrdpapi to allows the connection status
to be determimed. These functions are modelled on the Windows API
functions, but are not compatible with them. In particular, the error
handling is different.
A way for an application to receive events is also provided. At present,
only connect/disconnected events are implemented.
Add an option to allow effectively disable file system space checks for
some file managers before copying files to remote drives.
This is a temporary solution. A better solution is to provide each
remote drive with its own mountpoint, so that the xrdp FUSE filesystem
becomes POSIX compliant.
The current code doesn't allow for an empty string to be pasted to the
clipboard on the X11 side. This is done by some lock screen programs
to prevent information leakage.
1) Remove 'magic numbers' related to static channel name lengths, and
replace with CHANNEL_NAME_LEN, or CHANNEL_NAME_LEN+1, as appropriate.
2) Always add static channel definitions, even if they are malformed.
3) Log channels which the client sends, which aren't named in
the [Channels] section of xrdp.ini.
(cherry picked from commit 9092d898b7dceda713bd05b296ea8e8213ee614b)
The signal handlers for SIGTERM are put in place before the
sigterm object is created. If a SIGTERM is received between the
two, it is ignored and chansrv will not exit.
cppcheck 2.17.0 adds checks that a NULL pointer returned from malloc() and
calloc() is not used.
We do this quite a lot.
I've addressed this by adding functions g_malloc_nofail() and
g_calloc_nofail() which either allocate memory or abort.
functions are now called in places where we are not making these
checks.
Many of these checks are in test programs or example programs.
I've modified the list16 module to handle out-of-memory conditions.
This Coverity issue was encountered in a private build, but does not
appear to be in the Github CI build. Coverity is suspecting a copy-paste
betweem these lines in sound.c:-
1838: xstream_copyin(s, &g_stream_inp->data[g_stream_inp->size - g_bytes_in_stream], i);
1844: xstream_copyin(s, &g_stream_inp->data[g_stream_inp->size - g_bytes_in_stream], g_bytes_in_stream);
An inspection of the code shows this to bre a false positive
The errors in sesman/chansrv/chansrv_fuse.c appear to be false positives
caused by allocating xhandle->dir_handle, and then
casting xhandle to an integer in xfuse_handle_to_fuse_handle(), thus
hiding xhandle->dir_handle
For both occurrences, the logic has been simplified and made the same,
and a comment has been added to suppress the error.
This allows the `xrdp` part of the path `/etc/xrdp` where config files
are placed to be customizable. This change is useful when trying the
stable version and the devel version alternately.
The function as specified used gettimeofday() which is susceptible
to manual time changes, and is obsoleted in POSIX.1-2008. The
replacement uses clock_gettime(CLOCK_MONOTONIC, ) which is not
susceptible to manual time changes (at least on Linux) and cannot run
backwards.
Also, on systems with 32-bit integers, the value returned by this
function wraps around every 49.7 days. To cope with a wraparound in
a way compliant with the C standard, this value needs to return an
unsigned integer type rather than a signed integer type.
This is not year 2038 compliant on systems with 32-bit integers.
The call can be replaced with the standard C time() call. On
POSIX systems, time_t is guaranteed to be an integer type.
This seems a better fit than having it in the [Chansrv] section.
Also fixed a minor logging error relating to the parameter in
chansrv_config.c
(cherry picked from commit 6d2fd1be8451418f01dfbb203929e2838c1a979f)
This is useful for NFS-mounted home directories, where hosts
may otherwise produce colliding chansrv log file names
(cherry picked from commit cfc2e362b47103bc2c786252f331bb26b6ddecb5)
Chromium 130 won't save to our filesystem if we don't return a
max filename length.
Dummy parameters were tried for inode counts, but these do not seem to
be necessary. Not also that btrfs foes not return values for these
fields.
Some desktop environments are now checking for free space before
copying files to a destination.
To support this, the FUSE filesystem needs to convert the statvfs()
system call to the relevent PDUs from [MS-RDPEFS]
Chansrv now checks for the user sockdir being present. If it
isn't, it connects to chansrv and requests it be created.
This also needs the sesman port to be added to the chansrv
config struct.
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)
matt335672