[jira] [Created] (GUACAMOLE-2203) RDP Printer Redirection corrupts characters in PDF filenames

["Ondrej Linhart (Jira)" <ji...@apache.org>]

Ondrej Linhart created GUACAMOLE-2203:
-----------------------------------------

             Summary: RDP Printer Redirection corrupts characters in PDF filenames
                 Key: GUACAMOLE-2203
                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-2203
             Project: Guacamole
          Issue Type: Bug
          Components: guacamole-server
    Affects Versions: 1.6.0
         Environment: Debian, non-dockerized installation
            Reporter: Ondrej Linhart


When using RDP connection via Guacamole, it is possible to enable Printer Redirection.

This will produce a virtual printer inside that RDP session. Printing anything to this printer will result in the printed document being downloaded in client's browser as PDF generated by GhostScript.

In print-job.c we can see that the filename of this downloaded PDF is first seeded by a string constant, then later overwritten by the printed document's title (if present as Title in the PostScript raw stream). For document formats that do not have titles (like plaintext files), most editors use filename as the Title. If the file has not been saved yet, programs tend to fill filename candidates (Untitled, or Bez názvu in Czech Windows).

However, PostScript does not have a flag for content encoding, so Guacamole has no way of knowing the encoding of this Title. So it escapes all special characters and the produced filename of the PDF is corrupted (characters replaced by their numeric representation) if it contains special characters.

By testing, I have determined that the encoding of the Windows-produced PostScript stream when printing to the virtual printer follows a configuration option in Control Panel - Region - Administrative (tab) - setting for non-Unicode apps. This option tell Windows how to interpret/save data in applications with ASCII encodings.

When I change this option, the produced characters in the corrupted filenames are different. I can even check the (beta-marked) UTF-8 option here and it will produce two escaped numbers instead of one.

By contrast, when using the Drive redirection, the filenames with special characters are not corrupted so the pipeline for downloading files definitely can carry UTF or Unicode filenames all the way from the guacd backend to the frontend and client browser.

This is further demonstrated by running the guacd with DEBUG flag, where this log line already produces corrupted filenames when printing
{code:java}
guac_client_log(job->client, GUAC_LOG_DEBUG, "Beginning print stream: %s", job->filename); {code}
whereas this log line produces clean filenames with special characters when downloading
{code:java}
guac_user_log(user, GUAC_LOG_DEBUG, "%s: Initiating download of \"%s\"", __func__, path); {code}
I understand this happens because the file download method has pre-determined encoding of 16bit Unicode and thus guacd correctly interprets it as such, while the PostScript protocol does not have any encoding indication (I assume?) so guacd doesn't try to guess and just defaults to some single-byte encoding (probably ISO-8859-1?) and sanitizes the special characters.

Proposed solution:

Adding a new configuration variable to the RDP connection properties with encoding selection. The administrator would observe the mentioned option for encoding of non-Unicode apps (which affects the encoding of the PostScript printing Title) in their Windows machine, then set this variable to the same setting in the properties of that RDP connection.

Guacamole would then interpret the title in the selected encoding, producing a cleaner filename result even for documents with special characters in their Title. If the option would not be set, it would default to the current behaviour.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)