desktop-packages team mailing list archive

[John Doe <435719@xxxxxxxxxxxxxxxxxx>]

@ossjunkie: Didn't look at it before my previous comment as I hadn't
noticed it was there. It looks OK apart from the predictable location.
As you say, not a big adjustment to change that though.

# only apply when home directory is on NFS
if [ "$(stat -f -L -c %T $HOME)" = "nfs" ]; then
  # remove existing ~/.gvfs dir if empty
  rmdir ~/.gvfs
  if [ ! $? -eq 0 ]; then
    # remove link or move unempty dir/file
    if [ -h .gvfs ]; then
      rm ~/.gvfs
    else
      mv ~/.gvfs ~/.gvfs_moved_for_gvfs-fuse_on_nfs
    fi
  fi
  # create the symlink to unpredictably named directory with secure permissions
  ln -s "$(mktemp -d)" ~/.gvfs
fi

As well as creating an unpredictable location using  mktemp also means
you don't need to worry about permissions since by default it creates
files/directories with read/write for owner only.

-- 
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