gvfs-fuse fails to start on NFS mounted homes

Bug #435719 reported by Andreas Heinlein
38
This bug affects 6 people
Affects Status Importance Assigned to Milestone
gvfs
Expired
Medium
gvfs (Ubuntu)
Incomplete
Low
Ubuntu Desktop Bugs

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.

Tags: patch
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

Changed in gvfs (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Undecided → Low
Revision history for this message
Andreas Heinlein (aheinlein) wrote :

I followed your link and posted the bug upstream here:
https://bugzilla.gnome.org/show_bug.cgi?id=596176

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for sending the bug to GNOME

Changed in gvfs (Ubuntu):
status: New → Triaged
Revision history for this message
Erik Meitner (e.meitner) wrote :

I also have found this behavior to be a problem for our soon to be 60 workstation 200 user LDAP/NFS environment. We are running Ubuntu 10.04/amd64, autofs mounted NFS with rootsquashing on.

My workaround is: In /etc/gdm/PreSession/Default add the following before the "/sbin/initctl ..." line:

# create /gvfs if missing
[ ! -d /gvfs ] && mkdir -m 1777 /gvfs
# create users gvfs mountpoint there
[ ! -d /gvfs/$USER ] && sudo -u $USER mkdir -m 0700 /gvfs/$USER
# remove ~/.gvfs and create the symlink
sudo -u $USER rmdir ~/.gvfs
sudo -u $USER ln -s /gvfs/$USER ~/.gvfs

Revision history for this message
Erik Meitner (e.meitner) wrote :

Modify the second to last line of the above code to be:
sudo -u $USER rmdir ~/.gvfs || sudo -u $USER rm ~/.gvfs

Changed in gvfs:
status: Unknown → New
Revision history for this message
Andreas Heinlein (aheinlein) wrote :

Not exactly helpful for the bug report, but a hint at Erik: I have found quite a few traps in Ubuntu Software where it is assumed that the root user has access to the user's home directory, which is not the case in such an environment. Examples include usb-creator (fixed by now), pam_mount and others. This is a side effect of the Ubuntu way of allowing "normal" users to do administrative tasks via sudo.
Applications using PolicyKit apparently do not suffer from this, obviously usb-creator is a good example for this.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

a simpler/cleaner (?) way would be to add a script in /etc/X11/Xsession.d/, those are run as the user so no sudo'ing is necessary (and I used /tmp, for keeping the namespace cleaner). This is what we have now:

# create users gvfs mountpoint in /tmp
[ ! -d /tmp/.gvfs-$USER ] && mkdir -m 0700 /tmp/.gvfs-$USER
# remove ~/.gvfs and create the symlink
rmdir ~/.gvfs 2>/dev/null || rm ~/.gvfs
ln -s /tmp/.gvfs-$USER ~/.gvfs

Changed in gvfs:
importance: Unknown → Medium
Revision history for this message
ossjunkie (ossjunkie) wrote :

I just came across this bug when debugging OOo on SMB shares. Therefore i enhanced the proposed workaround by Timo so that the quirk only gets executed if $HOME is really on a NFS share. Tested it successfully on an old karmic machine and the current lucid workstations. Just see the attachment. Comments highly welcome.

Of course a proper solution would be a NFS mode in GVFS, but as this requires probably requires a lot of changes to GVFS this is no real solution for a backport. Therefore would we could include this script in the gvfs packages as SRU, as it only gets active on NFS setups.

tags: added: patch
Revision history for this message
John Doe (b2109455) wrote :

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

Revision history for this message
ossjunkie (ossjunkie) wrote :

@John: Did you take a look at the patch i have proposed, it wouldn't need a big adjustment for your needs.

Anyhow great that there is some interest in this topic. Would be great if we could bring a patch to the package in time for the precise release.

What the patch is lacking beside John's suggestion is a routine for the case where NFS isn't present anymore, so i works back and forth.

Revision history for this message
John Doe (b2109455) wrote :

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

Revision history for this message
gwir (gwir) wrote :

@John : I supposed it's a bash script?

Changed in gvfs:
status: New → Expired
Revision history for this message
Ritesh Khadgaray (khadgaray) wrote :

Please check, if this issue is still seen.

Thanks

Changed in gvfs (Ubuntu):
status: Triaged → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.