Bug#831873: xrdp created dir ${HOME}/.thinclient_drives which has permissions 000 belongs to root

[Andreas Tille]

[including Debian GNOME Maintainers as maintainer of gvfs into the
 discussion.  The issue id that when using xrdp 0.9 from Jessie backports
 gvfs seems to have trouble with the dir ~user/.thinclient_drives]

On Thu, Jul 21, 2016 at 12:16:09AM +0200, Dominik George wrote:
> On Mittwoch, 20. Juli 2016 23:03:11 CEST Andreas Tille wrote:
> > Hi Dominik,
> > 
> > On Wed, Jul 20, 2016 at 05:58:40PM +0200, Dominik George wrote:
> > > Some references:
> > > 
> > > http://serverfault.com/questions/188894/denied-root-access-to-user-mounted
> > > -fuse-file-system
> > > 
> > > In conclusion, I think it is arguable whether xrdp should create that
> > > directory. IMHO, the behaviour is correct.
> > 
> > But also the user can not see this dir.  I need to try again tomorrow.
> 
> Are you sure about that?

Yes.  On the production machine in question this was the case.  I have
rolled back to xrdp 0.6 to enable users to keep on working.  Please note
that besides this xrdp 0.9 was crashing randomly several times so the
rollback became necessary in any case.  It would be great if you could
raise your opinion on the thread in debian-edu list but this should be
discussed separately.

I'm now trying to reproduce the issue on a *different* machine which I
used for testing previously.

> Please verify again by doing the following:
> 
> Log in to the machine as root.
> Make sure the user is not logged in.
> Make sure that nothing is mounted on ~user/.thinclient_drives.

I've umounted everything now.

> rm -rf ~user/.thinclient_drives

done.

> Have the user log in through xrdp, with directory sharing enabled.

What do you mean by "with directory sharing enabled".  I'm just logging
in.  If there is a specific option please tell me how I can (de)activate
it.

> Have the user open a terminal and type ls -lhad ~/.thinclient_drives

$ ls -lhad ~/.thinclient_drives/
drwxr-xr-x 0 root root 0 Jan  1  1970 /home/tillea/.thinclient_drives/
$ mount | grep .thinclient_drives
xrdp-chansrv on /home/tillea/.thinclient_drives type fuse.xrdp-chansrv (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001)

> At this point. on my jessie machine, I see the directory owned by root with 
> permissions 755 (which is correct).

I confirm the directory is owned by root with permissions 755 zero byte
size and dated 1970-01-01.
 
> Look at the directory as root while the user is logged in. It should indeed be 
> shown with 000 permissions. *This is correct* - it is a design decision 
> (flaw?) of FUSE and well-known. Without special mount options, the krenel 
> refuses to disclose anything about a FUSE mountpoint to anyone, including 
> root. I think this is stupid - but that's how things are.

OK, I confirm the fact (permissions 000) and will not question those
design decisions.

> > > But in any case, this is not a bug, and even less an important one,
> > > because the creation and use of the directory as a FUSE mount point is
> > > not what prevents the users from seeing other mounts in Thunar.
> > > 
> > > Even if xrdp created a thousand fiels and directories with random
> > > permissions somewhere in the home directory, this should not prevent
> > > Thunar or gvfs from finding other mount points, fiels or directories.
> > > 
> > > Please report to the Thunar or gvfs maintainers that Thunar or gvfs
> > > break on an unreadable, random directory/mount point in the user's home,
> > > because that is exactly what happens and causes the issues for your
> > > users.
> > I need to track down this in more detail tomorrow.
> 
> Yep. Independent of whether it turns out there is a bug in xrdp concerning 
> this directory, it is at least *also* a serious bug in gvfs or Thunar that 
> such a directory breaks it.

gvfs maintainers are now in the row.
 
> > > I would be glad, if, as DD, not as reporter, you could advice me on
> > > whether to keep this bug as a wishlist item („should not create a
> > > directory in $HOME) or close it as invalid, because creating any random
> > > directories is not supposed to have side effects and breakage exists in
> > > Thunar/gvfs.
> > 
> > Well, if upgrading a package renders a system partly unusable this is
> > per definition
> > 
> >   critical
> >    makes unrelated software on the system (or the whole system) break,
> 
> Most certainly. But again, it is, above all, gvfs's fault to break because it 
> cannot read a directory. I see a million ways of using this for a DoS. There 
> are maybe two issues:
> 
>  1. xrdp might create an unreadable directory.
>  2. gvfs/Thunar breaks on an unreadable directory.
> 
> Number 1 is not proven to me yet, as I cannot reproduce it. I am very certain 
> that what you see is only true when running as root, and in that case, it is 
> correct as it is the expected behaviour of FUSE. Not a nice one, but expected. 
> I believe that gvfs breaking is a side-effect of it crawling mount points as 
> root, through policykit.

No idea about this.
 
> Number 2 is in fact a critical bug, but not in xrdp. Would you report a bug in 
> coreutils if the directory were created by mkdir and chmod and gvfs crashed on 
> it?

I'm fine with reassigning the issue but before doing so I want to hear the
opinion of the maintainers.
 
> You decided to install xrdp from bpo, knowing that it might break something. 
> Doing so, you found a bug concerning the compatibility between xrdp and gvfs 
> from stable. While this sure is annoying, it is still necessary to find the 
> real culprit.

I agree.  The problem is I can not even reproduce the issue on my test
machine.  The only visible difference between the production machine and
the test machine I'm using now to verify the issue is that on the
production machine pam_mount is used (which behaves strangely in
different ways - so I can't exlcude some issue here). 

I wonder whether gvfs maintainers might have some clever idea why Thunar
might have come up with

   "can't access .thinclient_drives"

(or similar message) and refuses to show the content of CIFS mounts which
are perfectly visible in bash.

Kind regards

       Andreas.

-- 
http://fam-tille.de