drive redirection issues with guacamole

[maennlse]

Hi,
i have issues with version 0.9.12 and drive redirection using guacamole (1.1.0) - the mounted "thinclient_drives" is empty (except a folder called GUACFS).

my os is centos 8 (https://github.com/maennlse/vagrant-guac-ad)
it does not matter if i use the provided xrdp package from centos,
or if i compile the latest version from source.

compiling versions 0.9.5 to 0.9.11 from source is working, the mounted "thinclient_drives" shows files as expected.

never the less, using a different rdp client (tested with remmina 1.3.10 on fedora 31) is also perfectly working.

so, to me it looks like some incompatibility between xrdp 0.9.12 and guacamole (1.1.0) ?

also i'm not sure if its really related to xrdp or guacamole, i'm writing here because for me the functionality 'broke' with updating xrdp to 0.9.12 (and not changing something on guacamole setup)

if there is any further information i can/should provide, please let me know. i'm happy to help.

edit: same behavior on ubuntu18.04, drive redirection with 0.9.12 (compiled from source) does not work, compiling 0.9.11 is working with guacamole (using remmina, both versions are working as expected)

thanks
Sebastian

[matt335672]

I'm not familiar with guacamole, but it seems likely that the 0.9.12 changes (which I'm more familiar with) are responsible for breaking something.

The logging for the redirected filesystems is poor at the moment - messages aren't going to the sesman log file, but to sesman stdout. I'm hoping to submit a PR to fix this in the future.

Using the 0.9.12 version from source, can you run sesman in a terminal window with the following or similar:-

sudo xrdp-sesman -n 2>&1 | tee ~/sesman.log

After the connection completes, we should hopefully have something useful in the log file.

[maennlse]

here is the requested debug output for 0.9.12 (and also for 0.9.11 to have a direct comparison)
the probably relevant part is this (0.9.11 | 0.9.12):

...
  xrdp-chansrv [2199700709]:       wBitsPerSample  16                                              |  xrdp-chansrv [2199823897]:       wBitsPerSample  16                                             
  xrdp-chansrv [2199700709]:       cbSize          0                                               |  xrdp-chansrv [2199823897]:       cbSize          0                                              
  xrdp-chansrv [2199700810]: sound_process_training: round trip time 101                           |  xrdp-chansrv [2199824003]: sound_process_training: round trip time 106                          
  [2199700810]: DEV_REDIR  devredir_proc_client_devlist_announce_req: 681 : num of devices announce|  [20200226-20:10:04] [INFO ] term_signal_handler: got signal 15                                  
  [2199700810]: DEV_REDIR  devredir_proc_client_devlist_announce_req: 711 : device_type=FILE_SYSTEM|  [20200226-20:10:04] [INFO ] xserver_fatal_handler: entered.......                               
  [2199700823]: DEV_REDIR  dev_redir_proc_client_core_cap_resp: 637 : got CAP_GENERAL_TYPE         |  xrdp-chansrv [2199839504]: child_signal_handler:                                                
  [2199700823]: DEV_REDIR  dev_redir_proc_client_core_cap_resp: 641 : got CAP_PRINTER_TYPE         |  xrdp-chansrv [2199839504]: child_signal_handler: child pid -1                                   
  [2199700823]: DEV_REDIR  dev_redir_proc_client_core_cap_resp: 651 : got CAP_DRIVE_TYPE           |  ------------------------------------------------------------------------------------------------
  [2199701635]: DEV_REDIR  dev_redir_lookup_entry: 1112 : fusep=0x7fed68034c10                     |  ------------------------------------------------------------------------------------------------
  [2199701635]: DEV_REDIR  devredir_fuse_data_enqueue: 1528 : +++ inserted FUSE_DATA=0x7fed68033f90|  ------------------------------------------------------------------------------------------------
  [2199701635]: DEV_REDIR  dev_redir_lookup_entry: 1149 : lookup for device_id=0 path=\\Download   |  ------------------------------------------------------------------------------------------------
...

just let me know if i can do/provide any further info

thanks.

sesman.log_debug_11.txt
sesman.log_debug_12.txt

[matt335672]

Thanks for the swift turnaround - just caught this as I came in this evening (here).

Thanks also for your excellent initial fault report!

Since you've getting a SEGV, the first thing to do is rule out #1487 which is either a direct cause, or masking another issue.

Can you apply the patch for #1487 directly to the v0.9.12 source tree and recompile xrdp-chansrv? Then try again and see what happens.

A direct link to the patch is here:-

https://github.com/neutrinolabs/xrdp/commit/72bece526bb5863d99a52546374c0c3b1561a61a.patch

[maennlse]

unfortunately i get the same behavior, also the sesman debug output is exactly the same.

sesman.log_debug_12_patch.txt

[matt335672]

Oh well, thanks for trying.
I'll mug up on guacamole and try to reproduce the issue here.
What are you running XRDP on, platform-wise? If we can find a stack trace for the SEGV somewhere that could be useful.

[maennlse]

you can 'easily' reproduce with the vagrant file from here: https://github.com/maennlse/vagrant-guac-ad (vagrant with winrm support required and the libvirt is used)
its surely not the 'smallest' setup available (it creates a windows domain controller, a centos host that starts guacamole using podman, and a ubuntu host) after the stack is online just connect to http://:8080/guacamole - login with the testuser (specified at the top of the vagrant file))

the above also describes the platform i'm running xrdp on...
(fedora 31 hostsystem -> kvm/libvirt -> centos8)

to be honest, i'm not much of a developer/debugger...
so if you give any advice on how to get any useful traces, ill provide it.

what i tried was:

strace -vvv -ff -o sesman.strace /usr/sbin/xrdp-sesman -n

grep fuse sesman.strace*

sesman.strace.7892:openat(AT_FDCWD, "/usr/lib64/xrdp/libfuse.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
sesman.strace.7892:openat(AT_FDCWD, "/lib64/libfuse.so.2", O_RDONLY|O_CLOEXEC) = 3
sesman.strace.7910:openat(AT_FDCWD, "/dev/fuse", O_RDWR)   = 11
sesman.strace.7910:mount("xrdp-chansrv", "/home/vagrant/thinclient_drives", "fuse.xrdp-chansrv", MS_NOSUID|MS_NODEV, "fd=11,rootmode=40000,user_id=100"...) = -1 EPERM (Operation not permitted)
sesman.strace.7930:execve("/usr/bin/fusermount", ["fusermount", "-o", "rw,nosuid,nodev,subtype=xrdp-cha"..., "--", "/home/vagrant/thinclient_drives"], ["SHELL=/bin/bash", "PATH=/sbin:/bin:/usr/bin:/usr/lo"..., "USER=vagrant", "LOGNAME=vagrant", "UID=1000", "HOME=/home/vagrant", "DISPLAY=:10.0", "XRDP_SESSION=1", "XRDP_SOCKET_PATH=/tmp/.xrdp", "XRDP_PULSE_SINK_SOCKET=xrdp_chan"..., "XRDP_PULSE_SOURCE_SOCKET=xrdp_ch"..., "PULSE_SCRIPT=/etc/xrdp/pulse/def"..., "_FUSE_COMMFD=11"]) = 0
sesman.strace.7930:openat(AT_FDCWD, "/dev/fuse", O_RDWR)   = 3
sesman.strace.7930:openat(AT_FDCWD, "/etc/fuse.conf", O_RDONLY) = 13
sesman.strace.7930:mount("xrdp-chansrv", ".", "fuse.xrdp-chansrv", MS_NOSUID|MS_NODEV, "fd=3,rootmode=40000,user_id=1000"...) = 0
sesman.strace.8061:execve("/usr/bin/fusermount", ["fusermount", "-u", "-q", "-z", "--", "/home/vagrant/thinclient_drives"], ["SHELL=/bin/bash", "PATH=/sbin:/bin:/usr/bin:/usr/lo"..., "USER=vagrant", "LOGNAME=vagrant", "UID=1000", "HOME=/home/vagrant", "DISPLAY=:10.0", "XRDP_SESSION=1", "XRDP_SOCKET_PATH=/tmp/.xrdp", "XRDP_PULSE_SINK_SOCKET=xrdp_chan"..., "XRDP_PULSE_SOURCE_SOCKET=xrdp_ch"..., "PULSE_SCRIPT=/etc/xrdp/pulse/def"...]) = 0

but this output is exactly the same on version 0.9.12 and 0.9.11, so this is not really much of a help.
nevertheless i uploaded the whole strace output (maybe you get some useful information from it)
sesman.strace.tar.gz

[matt335672]

Hmm - vagrant is sadly also something I'm not familiar with!

As you say, guacamole is containerized, so I'm (currently) fairly confident I can get that working fairly swiftly. If I fail to get anywhere, I'll try the vagrant route.

In the XRDP architecture, xrdp-chansrv is a separate executable from xrdp-sesman. xrdp-sesman manages user session at a high level. xrdp-chansrv runs in the context of the logged in user and provides access to sound channels, the clipboard, redirected drives, etc. That's the thing that's crashing.

Thanks for the info above, and the offer of more tracing info. I've had a quick play around with centos 8, and I'm having trouble getting it to generate a coredump of xrdp-chansrv from the EPEL RPM (which would be really useful). I suspect the xrdp-chansrv SEGV handler is getting in the way here. If I manage to think of a way to get more info from your setup, I'll ask.

[matt335672]

Well, I think I've found the root cause.

The redirection code in XRDP is sent a 'device id' from the other side to map the drive to. It seems guacamole is using a device id of zero which is not something that other clients do. This value is currently used for local files in the XRDP filesystem.

I've checked the specs, and I can see no reason why Guacamole should not use zero. I'll make some changes to allow zero to be specified for the remote filesystem.

[matt335672]

@maennlse - I've created a branch in https://github.com/matt335672/xrdp called guacamole_1505 which I believe will fix this issue.

The branch is based off of v0.9.12 rather than the latest devel commits.

If you'd rather work directly with v0.9.12 sources and patch them (I certainly would), the patch for the commit is here:-

https://github.com/matt335672/xrdp/commit/2688b983dcbb88c04b784dddc57b6360584200da.patch

I haven't put this through a full regression test yet, but I hope it will give you something to go on.

Please give it a go and get back to me at your convenience, or let me know if you have any questions.

[maennlse]

applied your patch to the 0.9.12 source and recompiled.
indeed, as you said, files and folders are shown now.

thanks for your work! 👍

will the fix be part of the next xrdp release? (provided the test are good)

[matt335672]

Well I certainly hope so, but I'm merely a contributor to this project (rather than a member).

Since 0.9.9, there have been regular four-monthly releases of XRDP (see https://github.com/neutrinolabs/xrdp/wiki/NEWS/a932bb83b1eade6a7d6605066c15d03f07ec64d4, so this will certainly be ready for April. However there's been talk of an expedited release to fix another problem also caused by the drive redirection problems, so I can't really say. I'll make sure I get a PR in ASAP, certainly within the next couple of days.

Thanks for the quick turnaround on my requests.

[metalefty]

@matt335672 @maennlse Thank you both! xrdp releases are four monthly. However, the latest v0.9.12 has some drive redirection related bug. Some of the bugs are regression. So we need to make an intermediate release. Sorry for the inconvenience.

#1487 and this #1507 are the fixes for drive redirection. I'll make a new release shortly.

[metalefty]

I've released v0.9.13.