On Wed, Jul 20, 2016 at 04:43:24PM +0200, Dominik George wrote:
> > Fuse is not used on this machine […]
>
> Yes, it is. xrdp uses FUSE to provide shared directories from RDP
> clients.
OK, I was not aware of this.
> You provided the link between the directory and FUSE in your original bug
> report.
>
> > and the directory did not exist in
> > users $HOME dirs until they start an xrdp session with the new xrdp
> > version.
>
> Yes. Before mounting a FUSE fielsystem, the directory needs to be
> created, obviously.
If this is the case its created with wrong permissions.
> > In other words: Under xrdp 0.6 from Jessie the problem did
> > not exist but occures with the backport of 0.9.
>
> Yes, but that's not because the directory is broken, but because old
> xrdp did not support shared directories.
I admit our users were used to this old behaviour and the new feature
does create rather trouble than advantages. Is there any chance to
disable this feature?
> > So something not normal is happening here. As I said the user can not
> > open or access it - no wonder if it has all permissions unset and
> > belongs to root.
>
> You actually didn't say that. You posted some commands and their results
> when run as root, and what you posted is normal behaviour with FUSE.
I intended to say this by
In MidnightCommander it is displayer in red with a leading '?'
dated 01.01.1990 is owned by root and has all permissions unset
(like `chmod 000 .thinclient_drives`)
> Could you please repeat these commands as the user running the xrdp
> session, from within the xrdp session?
Well, I have a good example: When I tested whether xrdp works I simply
logged into the defaul GUI xfce and immediately logged out afterwards.
I did not do any specific command at all but the broken directory
exists.
> > > I guess gvfsd in jessie is running as root and doing nasty magic through
> > > policykit or something?
> >
> > I checked the gxfsd processes on the machine and each user has a
> > separate one. There was no fidling around with gvfsd - just a plain
> > Debian stable installation.
>
> That does not mean that it does not try to access the directory as root.
I thought your question was whether there is some special gvfsd
configuration which is not the case.
> > > > $ grep -R thinclient_drives
> > > > debian/patches/fusepath.diff:- /* define FUSE mount point to
> > > > ~/xrdp_client, ~/thinclient_drives */
> > > > debian/patches/fusepath.diff:+ /* define FUSE mount point to
> > > > ~/.xrdp_client, ~/.thinclient_drives */
> > > > debian/patches/fusepath.diff:-FuseMountName=thinclient_drives
> > > > debian/patches/fusepath.diff:+FuseMountName=.thinclient_drives
> > > > sesman/sesman.ini:FuseMountName=thinclient_drives
> > > > sesman/chansrv/chansrv_fuse.c: /* define FUSE mount point to
> > > > ~/xrdp_client, ~/thinclient_drives */
> > > >
> > > > so it is definitely xrdp that's causing this strange dir.
> > >
> > > xrdp creates it as a FUSE mountpoint. but the consequences you see
> > > definitely look like a combination of the bad behaviours oF FUSE and
> > > gvfs in jessie (or in general?).
> > >
> > > I expect this to also happen with an sshfs mount. Could you try that?
> >
> > The mounts are samba shares (cifs).
> >
> > What exactly do you want me to try?
>
> $ sudo apt-get install sshfs
> $ mkdir .foobar
> $ sshfs u...@ezample.com: .foobar
>
> Then see whether it impacts Thunar as well.
>
> sshfs uses FUSE, just like xrdp, and I expect that you see the same
> behaviour with .ffobar after mounting sshfs on it as you see with
> .thinclient_drives.
I can try tomorrow - but as long as thunar has permissions to read the
dir I guess everything will be fine. Thunar tries to cache the
available directories - but it can not parse a dir that belongs to root
and has permissions set to 000. Not even root can access the dir. :-(
> >
> > > If you still think this is specific to xrdp, please explain why. If not,
> > > this should be discussed with the gvfs maintainers.
> >
> > I think xrdp is creating a directory that creates problems. IHMO the
> > fix would be to make sure xrdp does not create this directory (and
> > simply is using it if it exists).
>
> No, that is not a fix. It would mean that users would not be able to use
> shared directories over RDP unless they manually create some directory.
That's no difference to the current behaviour since the directory is not
accessible for anyone. However, the cifs mounted directories are
perfectly accessible in the xrdp session. I can easily browse them when
using bash or mc.
> As I cannot reproduce the problem (without Thunar/gvfs) and in fact find
> a working FUSE mountpoint in ~/.thinclient_drives, I think the real
> cause of the issues should be found instead of breaking user experience
> with xrdp.
Well, the user experience is *now* broken. You said old xrdp 0.6 was
not supporting shared directories. However, every user was able to
browse cifs mounted directories perfectly and now this is not possible
any more. I'm not sure whether I made my point clear: All our users
who ar depending from a graphical file browser are totally unhappy about
the upgrade and I will need to downgrade back to provide them a usable
machine.
Kind regards
Andreas.
--
http://fam-tille.de
