desktop-packages team mailing list archive

[John Doe <435719@xxxxxxxxxxxxxxxxxx>]

Timo's workaround is just what I was looking for. I wouldn't use
/tmp/.gvfs-$USER though since that's a predictable location. On a
machine where lots of people log in to it someone could maliciously pre-
create such directories for other users resulting in at best denial of
service and at worst them being able to access other people's files. I'd
use mktemp

rmdir ~/.gvfs 2>/dev/null || rm ~/.gvfs
ln -s "$(mktemp -d)" ~/.gvfs

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/435719

Title:
  gvfs-fuse fails to start on NFS mounted homes

Status in GVFS:
  New
Status in “gvfs” package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: gvfs

  gvfsd usually start a gvfs-fuse-daemon for GVFS mounts, which fuse-
  mounts to $HOME/.gvfs. This fails if the home directory resides on an
  NFS share with root squashing enabled. Thus, users in a
  corporate/networked environment with such NFS homes cannot use gvfs
  effectively, since a lot of applications rely on the fuse mount.

  For those unfamiliar with NFS, root squashing means the local UID 0 is
  mapped to the anonymous/nobody UID on the remote system when it tries
  to access the NFS share. Since home and subdirectories have
  permissions 0700, $HOME/.gvfs cannot be accessed by root in this case.
  This makes the mount() call of gvfs-fuse-daemon fail (verifiable with
  'strace gvfs-fuse-daemon /home/user/.gvfs').

  There are two solutions to this:
  a) disable root squashing
  b) move the .gvfs directory somewhere else

  a) is not a good choice for security reasons. b) seems not to be
  possible at the moment. I looked at the sources for the current
  (jaunty and karmic) gvfs package and found

  mount->fuse_mountpoint = g_build_filename (g_get_home_dir(), ".gvfs",
  fs_name, NULL);

  in daemon/mount.c. Even though gvfs-fuse-daemon can be called with any
  path you like, it looks like the path which gfvsd uses for the call is
  hard-coded. I was able to symlink /home/user/.gvfs to /tmp/.gvfs, and
  this works. But I am not sure if that is a good solution.

  I would like to ask the package maintainers to a) include a README.NFS
  in the package which points out the problem and workaround (I can
  write one if you like) and b) forward this bug upstream to the right
  place, so the path with which gfvs-fuse-daemon gets called can be
  configured.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gvfs/+bug/435719/+subscriptions