The data provided by local applications can be actually encoded in
UTF-16 (e.g., Firefox does this to HTML). UTF-16 allows embedded null
bytes so we should not use strlen() to fix up the data. The HTML format
synthesizer can handle trailing null bytes just fine and can detect
whether it deals with UTF-8 or UTF-16.
Most of the functions is this file are internal-use callbacks so they do
not need to be exported from the compilation unit. Mark functions static
as appropriate.
Now that we've got everything in place to handle files it's time to tell
the server that we can actually do this.
MS-RDPECLIP 3.2.5.1.3 Sending a Client Clipboard Capabilities PDU asks
us politely to not advertise file clipping support if the server did not
do that itself. Thus we need to parse the capabilities sent by the
server and take a note whether it supports file clipping.
There is also no point in advertising file clipping support if
wClipboard failed to initalize any local file subsystem, in which case
we cannot handle files for real. Take a note of this as well when we
register the file formats.
If everthing is really in place and the stars shine upon us then we are
allowed to set CB_STREAM_FILECLIP_ENABLED in the capabilities. There is
no command line switch to disable file clipping (and there is little
reason to), so we always support it if we can.
We also set an additional flag CB_FILECLIP_NO_FILE_PATHS flag in the
capabilities because it seems to be necessary for the server to send the
"FileGroupDescriptorW" format to us. Otherwise the server will only send
the old CF_HDROP format which can't be handled well without enabled disk
drive redirection and a properly negotiated server-side temporary
directory.
xf_cliprdr_server_file_contents_request() handles the
CLIPRDR_FILECONTENTS_REQUEST which is sent by the server to retrieve the
size or data of a single file. The server can only request one of these
things at a time, do confirm this.
The actual handling of the requests is done by wClipboardDelegate. In
order to handle its resposes we register a bunch of our own callbacks
which simply pass the responses to the server.
In case of an error we should always send a CB_RESPONSE_FAIL to the
server. If we do not then the file transfer progress dialog may end up
hanging in the remote session forever until the user logs out or kills
explorer.exe. We do wnat this.
To handle a new format we should first be able to transform the format
name from the local clipboard owner into its remote representation. In
our case this will be trasforming the "text/uri-list" target into the
"FileGroupDescriptorW" named format.
Add CB_FORMAT_TEXTURILIST to identify the local format by its ID during
the data conversion step. This numeric ID has nothing to do with the ID
which will be sent to server. It's a bit weird, but that's how XFreeRDP
works.
After that add a new client format with this ID and appropriate local
and remote format names (in atom and formatName fields respectively).
Do this only if wClipboard actually supports "text/uri-list" format.
(It could fail to initialize the local file subsystem, in which case
it will fail all file-related requests and there would be no point in
advertising the file format support in the first place.)
Finally, handle the actual format data request for a new named format
in xf_cliprdr_process_requested_data(). Remember to convert the
FILEDESCRIPTOR array we receive from wClipboard into the
CLIPRDR_FILELIST expected by the server. Also take care to not leak
memory during this conversion.
Note that this handles only the CLIPRDR_FORMAT_DATA_REQUEST. The server
is still not able to retrieve the file content as this is done via a
separate request-reply sequence.
Unify error handling in xf_clipboard_new() by using a common cleanup
code path. This fixes a leak of clipboard->system and format names when
an error occurs during initialization.
Also reformat the code to fit into 100 column limit without this line
break insanity and with improved readability.
I do not particularly like to use a variable with such a descriptive
name 'n' far away in the error handling part, but its short name is
kinda important for readability so let's keep it as is.
FreeRDP uses clipboard->data to cache the result of the Windows->X11
clipboard format conversion, and xf_cliprdr_process_selection_request()
immediately provides this result to local applications if they request
the same clipboard format again. This saves us a possibly costly
conversion in case where the user pastes data repeatedly.
However, this caching mechanism did not support raw clipboard transfers
where the unmodified data is passed between two FreeRDP clients. We use
the same XClipboard protocol for this, so the clipboard->data is in play.
We clear the cached value when we receive new data from the server, so
initially raw transfers are fine. But if some local application (e.g.,
a clipboard manager) asks for some data format before the data is pasted
into the second FreeRDP session then clipboard->data will contain the
*converted* data. And this converted cached data will be provided to
the second FreeRDP session as a part of the raw data transfer. Instead
we should have provided the original data.
In order to achieve this we are now caching the original data in the
same way as the converted one, and the original data is now correctly
provided when the second FreeRDP session asks for a raw data transfer.
[channels/tsmf/client/gstreamer/tsmf_X11.c:317] -> [channels/tsmf/client/gstreamer/tsmf_X11.c:322]: (warning) Either the condition '!decoder' is redundant or there is possible null pointer dereference: decoder.
[channels/tsmf/client/gstreamer/tsmf_X11.c:470] -> [channels/tsmf/client/gstreamer/tsmf_X11.c:475]: (warning) Either the condition '!decoder' is redundant or there is possible null pointer dereference: decoder.
[channels/tsmf/client/gstreamer/tsmf_X11.c:472] -> [channels/tsmf/client/gstreamer/tsmf_X11.c:475]: (warning) Either the condition '!decoder' is redundant or there is possible null pointer dereference: decoder.
[channels/tsmf/client/tsmf_media.c:179] -> [channels/tsmf/client/tsmf_media.c:181]: (warning) Either the condition '!stream' is redundant or there is possible null pointer dereference: stream.
[client/Windows/wf_cliprdr.c:2219] -> [client/Windows/wf_cliprdr.c:2222]: (warning) Either the condition '!formatDataResponse' is redundant or there is possible null pointer dereference: formatDataResponse
[client/Windows/wf_cliprdr.c:2445] -> [client/Windows/wf_cliprdr.c:2448]: (warning) Either the condition '!fileContentsResponse' is redundant or there is possible null pointer dereference: fileContentsResponse.
[client/X11/xf_cliprdr.c:911] -> [client/X11/xf_cliprdr.c:913]: (warning) Either the condition '!clipboard' is redundant or there is possible null pointer dereference: clipboard.
[client/X11/xf_graphics.c:504] -> [client/X11/xf_graphics.c:506]: (warning) Either the condition '!xfc' is redundant or there is possible null pointer dereference: xfc.
[libfreerdp/core/transport.c:861] -> [libfreerdp/core/transport.c:863]: (warning) Either the condition '!transport' is redundant or there is possible null pointer dereference: transport.
[server/shadow/shadow_server.c:777] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:778] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:779] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:781] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:782] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:783] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:784] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:785] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:787] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:789] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
- fixed invalid, missing or additional arguments
- removed all type casts from arguments
- added missing (void*) typecasts for %p arguments
- use inttypes defines where appropriate
* Make sure that numFormats has reasonable value
This will help catching errors like writing -1 as an unsigned number
of formats into the serialized stream, or trying to read the property
after someone else erroneosly messed with it, or other similar mistakes
which would result into reading and then sending garbage to the server.
We read the list xf_cliprdr_get_raw_server_formats() from an X window
property. Properties generally cannot be larger than 4 KB and each
format requires at least 5 bytes (most of them are named, though),
which gives us 512-ish limit on the number of formats we can squeeze
into the property.
However, it's hard to find an application that provides more than
20 formats (I've seen like 15 for MS Office apps), thus I believe
we can safely assume than anything that does not fit into a byte
means that we are reading garbage rather than a good format list.
* Check for the end of stream when reading format names
This also prevents reading garbage and getting segmentation faults
and Valgrind warnings when somebody somewhere sometimes forgets to
put a terminating null character where it belongs.
strnlen() and strndup() functions are provided by POSIX.1-2008
which we can reasonably expect to be available in 2016.
The second step of raw transfer is to transfer the format data itself.
This has been already implemented in XFreeRDP before, but several
tweaks are required for it to work correctly.
The idea of raw data transfer is to request for _FREERDP_RAW clipboard
format while putting the actual formatId into _FREERDP_CLIPRDR property
where the requested data is expected to arrive to. Then the clipboard
owner will check for the real formatId and deliver the expected data.
This stays true, but the check is performed in a more straightforward
way, and CF_RAW format (numerically equal to zero) is not considered
an unknown destination format when performing (identity) conversions
with wClipboard. This is not an issue because wClipboard will allow
only identity conversion for CF_RAW, it will fail if something else
is going to be converted into CF_RAW.
The first part of raw transfer sequence is to transfer the format
list of the session A into the session B. Then we will be able to
request/reply with raw data using proper format IDs.
xf_cliprdr_server_format_list() of the session A now exposes the
raw server format list. As soon as the list is received, it is
serialized and put into _FREERDP_CLIPRDR_FORMATS property.
xf_cliprdr_get_requested_targets() of the session B now checks
whether the clipboard owner is a FreeRDP session with enabled
raw transfer capability. If it is, the raw format list is simply
extracted from _FREERDP_CLIPRDR_FORMATS of the clipboard owner.
Otherwise, the format list is populated from the usual TARGETS
clipboard format.
Some time ago there was a property _FREERDP_CLIPRDR_ID which was indended
to indicate that an XFreeRDP window owns a clipboard. This was necessary
for raw transfers. This property was used by xf_cliprdr_is_self_owned()
function. However, raw transfer support was broken and the meaning of
xf_cliprdr_is_self_owned() gradually changed into checking whether
the *current* window owns the clipboard, not just any XFreeRDP window.
Thus _FREERDP_CLIPRDR_ID was removed in a4580923e7 (xfreerdp/clipr:
fix self owned test and hardening).
However, now we are going to fix raw transfers and we need that property.
This patch reintroduces a similar property "_FREERDP_CLIPRDR_RAW" which
indicates that a window is an XFreeRDP window with enabled raw transfer.
It is currently used by xf_cliprdr_server_format_data_request() to
correctly request format data from another XFreeRDP instance via raw
transfer protocol.
This property can be queried from the clipboard owner with the function
xf_cliprdr_is_raw_transfer_available() and can be enabled or disabled
on the current window by xf_cliprdr_set_raw_transfer_enabled().
Disabling raw transfers will be necesary to correctly implement file
transfers in the future. However, currently raw transfers are always
enabled.
xf_cliprdr_send_data_response() is consistently called with NULL
data pointer as a way to report errors, but it was not setting
the msgFlags field accordingly.
Sometimes Windows sends strings with excess null terminating bytes.
For example, when one copies digits from calc.exe. At the same time,
some local applications freak out when they encounter null bytes
(at least LibreOffice is known to be replacing them with '#').
According to the specification of UTF8_STRING format [1], the string
data must not contain any trailing null bytes. So they all should be
trimmed, not only the last one.
Also, if the trailing null byte is not present, the length should not
be adjusted. For example, Firefox is actually sending "HTML Format"
without a null byte while Internet Explorer adds one. The spec for
text/html format [2] says nothing about the teminating null byte, so
we are free to remove it, but at least we should not mistakingly
delete '>' character of "</html>" tag when it is the last character.
[1] http://www.pps.univ-paris-diderot.fr/~jch/software/UTF8_STRING/UTF8_STRING.text
[2] https://www.ietf.org/rfc/rfc2854.txt
Clipboard formats are identified by numerical IDs and literal names.
We can keep using arbitrary defined IDs for local clipboard formats
as we are sure that they have some fixed meaning, but the server can
and will be using its own IDs, which can be different from ours for
the named formats.
Therefore:
1) A correct way to compare a local format to a remote one is
to check the names first, and only then compare their IDs.
(Extra care should be taken to support short format names.)
2) Server IDs cannot be used with wClipboard directly when dealing
with named formats. Format name should be used to extract correct
local ID for the use with Clipboard{Set,Get}Data().
Also, I find the notion of 'alternate' format IDs to be confusing.
We either deal with a fixed ID format (declared in <winpr/user.h>),
or a format that was given an arbitrary fixed ID for local use
(defined in <freerdp/channels/cliprdr.h>), or a remote format
identified by a pair of an ID and a name. Format IDs can be local
and remote, but there are no 'alternates'.
So now:
1) A new function xf_cliprdr_formats_equal() is used to compare
formats correctly in xf_cliprdr_get_server_format_by_atom()
when searching for a server format corresponding to a local
one, and in xf_cliprdr_server_format_list() when constructing
a local TARGETS list from the server format list.
2) Correct local format IDs are used with wClipboard conversions
by xf_cliprdr_process_requested_data() and
xf_cliprdr_server_format_data_response().
3) We refer to formatId and formatName when doing requests,
and srcFormatId and dstFormatId when doing conversions,
instead of using formatId and altFormatId for both purposes.
4) Server format ID and name are used to identify cached clipboard
contents. The name is compared directly as a pointer because it
will be a pointer from the same clipboard->serverFormats array.
Also, the clipboard contents are invalidated when format list
arrives, so xf_cliprdr_server_format_list() now also clears
the format ID and name together with the data.
The functions now have appropriate names which tell what exactly
they are searching for:
xf_cliprdr_get_client_format_by_id()
Get a client-provided format by client-side ID.
xf_cliprdr_get_client_format_by_atom()
Get a client-provided format by client-side format name.
xf_cliprdr_get_server_format_by_atom()
Get a corresponding server format by client-side format name.
The return types of functions have been adjusted accordingly and
correct formats are now used everywhere without mixing them up:
client-side formats are used for client -> server data flow,
while server-side ones are used for server -> client tranfers.
This resolves the issue #1414 as, for some reason, xfreerdp required
server format list to be present to be able to provide its own client
formats. Actually, we need only client format list to provide these.
Also, CF_RAW special case is handled in a more elegant way: it is
assumed to be present in every server format list (which is true).
- xf_cliprdr_is_self_owned() lied if multiple xfreerdp instances were
running.
- fixed a few unchecked callocs
- added/modified and handled some return values in compliance with
the new hardened channel api
xf_cliprdr_process_selection_notify calls xf_cliprdr_send_client_format_list
if the SelectionNotify event property was None.
xf_cliprdr_send_client_format_list called XConvertSelection even if there
was no clipboard owner. In that case the XServer generates a SelectionNotify
event to the requestor (us) with property None and so on ...
The most obvious fix is to ensure that XConvertSelection is not called if
the owner is None which is done in this commit.
