This might be a HUGE security issue. E.g. I wouldn't want crappy backup tools at my work computer to mirror my SFTP mounted computer at home (which has my music on it).

I'd suggest WONTFIX.

If you cannot trust the root user at your work computer, then you're in big trouble anyway if you access your home computer. Not using --allow-root doesn't give you any protection against malicious intent, so this is not a *security* issue at all.

I agree though that the situation you describe can be be quite an *inconvenience*. But it isn't immediately obvious to me why this inconvenience is somehow worse than the ones described in the original bug report.

There is, however, a solution that may take care of both issues: FUSE could return dummy attributes for stat() on the mountpoint while still permitting access to the mountpoint itself. This is sort of a hack, but it should only be necessary until private namespaces are supported in the mainstream distributions (see
http://sourceforge.net/mailarchive/message.php?msg_name=87myfyxb1k.fsf%40nokile.rath.org and following discussion)

(In reply to comment #2)
> If you cannot trust the root user at your work computer, then you're in big
> trouble anyway if you access your home computer. Not using --allow-root doesn't
> give you any protection against malicious intent, so this is not a *security*
> issue at all.
> 
> I agree though that the situation you describe can be be quite an
> *inconvenience*. But it isn't immediately obvious to me why this inconvenience
> is somehow worse than the ones described in the original bug report.

Remember that the "nfs root squash" option is there for a reason. This isn't really much different. So what we have now is probably a sane default.

That said, I wouldn't mind having an GConf option allow the local uid 0 to access the gvfs FUSE mount. But it would probably have to be off by default (distros / sites / orgs / users / etc. can tweak this as desired).

(In reply to comment #1)
> This might be a HUGE security issue. E.g. I wouldn't want crappy backup tools
> at my work computer to mirror my SFTP mounted computer at home (which has my
> music on it).
> 
> I'd suggest WONTFIX.

I took the time to answer this sort of 'crappy' authoritative advice !

Most admins are using rsync sophisticated scripts for HUGE backups and even don't
always "mount" their music at work ;-) 

I don't use gnome desktop but gtk for some apps ... and I AFFIRM that it is
not 'sane' nor 'normal' to come and create a .gvfs read-only directory in a $HOME dir

That is poor hacking as, (it was already said by other people) it is possible to
manage this bloody mount point in /mnt (we are in Unix ... not M$) and to maintain
all ROOT rights.

Thanks to consider that all window manager are nice layers which should never block any vital basic applications ...

Thanks to move .gvfs elsewhere with acceptable permissions.
Best regards,
Serge.

If gvfs will be placed in /tmp/$user-gvfs, somebody (root?) will be able to f*ck down remote system when cleaning temporary files by "rm -rf /tmp/*". /tmp is for TEMPORARY DATA ONLY and if you are mounting remote filesystem with non-temporary data, this can be serious problem. /tmp is supposed to be removable any time without causing some bigger problems and i am cleaning it up this way sometimes... also some system maintenance utilities that are made to clean the system can remove contents of /tmp.

(In reply to comment #5)
All of that confirms that we cannot accept such behavior from a directory use which breaks UNIX rules and things have to be done differently as all other api do.  Root is root and has access to everything.

An example : if you are using a distant rsync based backup, these permissions forbid ssh-backup root access and breaks the backup stream ... and force you to umount manually this bloody .gvfs directory before backup start ... What is rarely predictable for the scripts.

It seems that someone refuse to comply with rules ;-) No config files or directory can use perm 500... it is not acceptable.

Thanks,
Serge.

(In reply to comment #5)
> If gvfs will be placed in /tmp/$user-gvfs, somebody (root?) will be able to
> f*ck down remote system when cleaning temporary files by "rm -rf /tmp/*". 

No, he can't. Even root cannot access a fuse fs mounted without allow_root.

(In reply to comment #7)
> No, he can't. Even root cannot access a fuse fs mounted without allow_root.

yes. thats why i hope that this feature request will not be accepted. root should have access to local fuse filesystems like NTFS disks, but he should not have access to encrypted (encfs) or remote (sshfs) filesystems.

but mounting something to /tmp is still not according to "UNIX rules".

What about /mnt/gvfs-$USER/ instead of ~/.gvfs/ ?

(In reply to comment #9)
> What about /mnt/gvfs-$USER/ instead of ~/.gvfs/ ?

Sounds like an excellent idea to me.

cool ;)
maybe /mnt/gnome-vfs/$USER/ will be nicer?

i don't like to see ~/.gvfs, either. #601474

any place else even ~/.gnome2/gvfs will be better. ;)

btw imho dot files/directories in home should be moved into the ~/.config/
i hate hundreds of dotfiles with some configuration or something created by almost every application i launch...

just look:
.0verkill .AbiSuite .FRD .ICEauthority .TwinAuth .VirtualBox .WorldOfGoo .XaoSrc .adesklets .adobe .airoscript .arduino .aspell.cs.prepl .aspell.cs.pws .audacious .audacity-data .aurvote .autozen .avast .bash_history .bash_history~ .bash_profile .bashrc .boswars .cache .cmus .config .conkyrc .covers .cpan .cups .dasher .dbus .ddd .designer .desklets .dfmdesk .dfminfo .dia .dmrc .dosbox .dunerc .eagle .eaglerc .eclipse .eduke32 .electricsheep .elinks .esd_auth .evolution .face .fltk .fluxbox .fontconfig .fr-pbnDgP .fr-rh9bWv .fr-xTElKS .free42 .freecraft .frostwire4.18 .gconf .gconfd .gegl-0.0 .gerix-wifi-cracker .ggseq .gimp-2.6 .gitconfig .gksu.lock .gmerlin .gmerlin-avdecoder .gmpc .gnome .gnome2 .gnome2_private .gntpositions .gnupg .gramps .gstreamer-0.10 .gsvn .gtk-bookmarks .gtk-gnutella .gtklp .gtkrc-2.0 .gtktermrc .gvfs .hplip .htoprc .icedteaplugin .icons .ideskrc .idesktop .ies4linux .indywikirc .inkscape .irssi .jackbeat .jap.conf .java .kaxtv.ts .kaxtv1.ts .kde .kde4 .lazarus .lesshst .lftp .libquicktime_codecs .limewire .links .lmmsrc.xml .local .macromedia .mathomatic_history .mbscore .mc .microemulator .milkytracker_config .miro .moc .mozilla .mplayer .mtpaint .nautilus .nbprofiler .ncftp .nessusrc .nessusrc.cert .netbeans .netbeans-derby .netbeans-registration .netx .netxrc .octave_hist .openme .openme.prefs .openme.presets .openoffice.org .opera .orca .pitivi .pki .printer-groups.xml .purple .putty .pyjama .qt .qtoctave .recently-used .recently-used.xbel .rnd .schism .sheep .silc .ssh .subversion .supertux2 .sw3 .swscanner .teeworlds .themes .thumbnails .tomboy .tomboy.log .tvtime .unison .viminfo .visualvm .wapi .wine .wireshark .wvdial.conf .xlogo .xscreensaver .xsession .xsession-errors .xsession-errors.old .xvidcaprc .zenmap .zynaddsubfxXML.cfg

^^^omg...

(In reply to comment #13)
> btw imho dot files/directories in home should be moved into the ~/.config/
> i hate hundreds of dotfiles with some configuration or something created by
> almost every application i launch...

This has nothing to do with the bug at hand.

I agree that ~/.gvfs should become /mnt/gnome-vfs/$USER/ or similar. Imho /mnt is the proper location for this, whereas ~/.gvfs and /tmp aren't.

i've got another idea... gnome is mounting all extra pen-drives, CDs, etc. to /media/, so maybe /media/gnome-vfs/$USER/ is the right place...

I interpret /media as targeted for (the dynamic creation of) mounts for removable media and the likes. The GVFS seems a more 'permanent' set of mounts to me, much more comparable to 'normal' disk mounts.
If I would want to make a NFS mount or other network-oriented mount, outside of the GVFS-mechanism, I would say that /mnt is the proper place to do that.

Putting it into /mnt/gvfs/$USER, /mnt/.gvfs/$USER or similar, still seems the proper thing to do.

(In reply to comment #3)
> Remember that the "nfs root squash" option is there for a reason. This isn't
> really much different.

Yes it is.  AIUI, NFS root squashing is enforced by the NFS server to protect root-owned files on the server from being trashed by a compromised machine (though the machine can trash all user home directories, which is almost as bad).  The FUSE restriction is supposed to protect naive root-owned processes from being confused by wandering into a malicious user-mounted filesystem.  As stated in comment #2, this does not prevent root from accessing the filesystem if he/she really wants to.

In any case, the right solution is to move the gvfs-fuse mount point.

Obviously this bug shouldn't be still UNCONFIRMED.

I'd like to make a modest proposal as to how to fix this.

FUSE is turning out to be some really scary stuff. In addition to giving the system the power to create rocks so big it itself can't list them, it opens up the door to some nasty null pointer exploits, and get this: it doesn't even respect /etc/modprobe.d/blacklist.conf . That's some Bonsai Buddy crap right there.

The only way I've found to disable fuse (and thus this problem) is this:

cat >> /etc/modprobe.conf << "EOF"
install fuse /bin/true
EOF

which works like a charm. So that's my proposed bugfix: rather than tracking down a gnome-only environment variable and then painstakingly poring through gnome's log in and creation procedure to find the exact moment you need to export it, just turn fuse off entirely and find a solution that doesn't suck for sharing across a network. There's plenty of other fish in that sea, believe me.

FUSE DEVELOPERS: just an idea: mount something read only,then do a union layer in ordinary user filespace where you handle transactions, and then only send transactions where the UID matches up to the real filesystem if you insist on restricting things by UID. This way, if root or anyone else that has access (root ALREADY HAS access to this directory, by the way, even if indirect; he can already umount and su to the user that owns the directory at will) decides to do something like an rm -rf /home/averagejoe/.gvfs, the changes won't propogate.

Better idea: send all transactions over as the user identified as owning the mount point, whether they come from root or the user that owns it. Or wow, I just had something that totally blew my mind, maybe a user could even extend this and specify some sort of "group" of people that they trusted to act as them with regard to the network. Or maybe even make some sort of list, that would let you control access. An access control list, as it were.

Man, if only there were some sort of commonly used and cherished way of setting permissions for files and folders that people on Unix-likes were already comfortable with, that would prevent FUSE from hackily reinventing the wheel like this.

Preventing root, who is capable of becoming anyone including and especially the owner of a file that sticks out like a sore thumb when he's trying to administer it, from accessing a file or directory, is silly. It's like telling Superman that only Clark Kent is allowed inside a building; I'm not really sure what you were trying to accomplish here.

I think you should talk to FUSE developers first. I'm welcome for any ideas from their side.

I had no intention of killing the discussion, and regret some of what I'd posted earlier on in the year. I also think I delayed a perfectly acceptable fix, moving to /mnt/gvfs/user. Posting while frustrated is never a good idea, and most of the help I found online amounted to "why do you want to remove gvfs".

So since there is a developer here, I'd like to apologize to you directly.

The upshot is that there is no easy way to disable fuse through standard methods (e.g. a blacklist entry), but I agree that's something to take up with fuse developers.

So I thought I'd be more helpful this time around. What I'd like to propose as a fix, in addition to moving the directory, something like

mount -t unionfs -o dirs=/mnt/gvfs/user:ro;/home/user/.gvfs:rw

Or something similar. Basically, a union layer would, I feel, make all parties happy. rm -rf wouldn't destroy any remote data, and every directory could be handled like normal.

Since there does (hopefully, if I didn't scare him off) seem to be a developer lending his ear here, I'd like to add that there is another problem that should be addressed. There needs to be an easy way to configure gvfs using traditional means. There's nothing in fstab for gvfs. There are no configuration files. And I think that's a huge part of the frustration folks like myself are obviously feeling. If I as a sysadmin could decide how and where gvfs was going to mount, that would be ideal.

That sentence with "upshot" mentioned the /etc/modprobe.conf "fix" for fuse in it originally.

I also realized that the union is not a solution as far as removing remote files. One possible solution here that I can think of would be to look at the white-out files. If all the files in /home/user/.gvfs were destroyed, then the sync simply wouldn't happen. Otherwise, the activity would likely be intentional, and all the white-outs could be applied to /mnt/gvfs/user .

(In reply to comment #22)
> What I'd like to propose as
> a fix, in addition to moving the directory, something like
> 
> mount -t unionfs -o dirs=/mnt/gvfs/user:ro;/home/user/.gvfs:rw
> 
> Or something similar.

If the admin runs "rm -rf /mnt", that will already trash other mount points.  I don't think it's necessary to defend against this in gvfs.  In any case, that would be another bug.

Just to note that the opengroup manpage of the stat() function explicitly tells that:"Read, write, or execute permission of the named file is not required"

http://pubs.opengroup.org/onlinepubs/009695399/functions/stat.html

But in the case of .gvfs, stat() fails with EACCES if called from root.

# stat .gvfs
stat: cannot stat '.gvfs': Permission denied

This seems to me a blatant POSIX violation, that indeed breaks most if not all backup applications run by root.

I realize that this is mostly a fuse problem, but gvfs uses fuse, so it's also a gvfs bug. And moving it to /mnt/gvfs/$user is something that at least will reduce the pain of this bug.

Note also that having an intermediate directory like "/gvfs/" is needed, because it will allow to add exclude rules even to backup programs that always call stat() even before applying exclusion rules.

nowadays, we use /run/user/<UID>/gvfs for mounting the fuse filesystem

So there are few things to mention, from past experience.

First, we moved the mountpoint in /run/user/<UID>/gvfs as Matthias said, with fallback to the old ~/.gvfs/ when /run is not accessible (but that's quite rare these days). So backing your homedir up should not be a problem anymore.

With this move, we've been immediately hit by another serious issue. As long as /run/user is meant as a temporary storage, temp files cleaning systems took place and started doing their job. We were not aware of such functionality at the time the change was done but yeah, the risk was there from the beginning. Fortunately, in case of systemd-tmpfiles all attempts were done with 0 UID/GID, thus not being able to access anything. The cleaning phase is set to 10 days by default. Hopefully these things are clever enough not to follow mounts in the tree (didn't check, doesn't change a thing anyway). 

Related info: https://bugs.archlinux.org/task/32715 (why this has not been reported upstream?)

That only leads me to necessity of preserving protection even from root. There's not a single reason to have gvfs mounts accessible for anybody else, the whole idea of gvfs fuse daemon was just to provide fallback for non-GIO apps within a single desktop session.

I'm currently checking whether is FUSE able to provide different contents for different UID/GID so that we could supply empty dir for root and stay accessible.

Created attachment 235417 [details] [review]
Proof of concept patch for reporting fake contents

FYI, a systemd tmpfiles.d exclusion file has been committed in master.

Attaching a patch that implements my thoughts from the last comment. With this patch, users other than the mount spawner are getting zeroes, empty contents.

This allows to work around long-standing problems, stat-ing and listing the mountpoint works without error, as well as statfs and df. All other operations are still returning "Permission denied" error.

Of course you need to activate user_allow_other in /etc/fuse.conf first which is a major blocker for getting this idea in production widely.

Useful FUSE resources:
http://www.cs.hmc.edu/~geoff/classes/hmc.cs135.201001/homework/fuse/fuse_doc.html
http://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/security.html

@ Tomas #27

As to this not being reported upstream; I (the archlinux reporter) was referred to this very thread which, in an only slightly different context, is the same problem, and which was therefore already reported here. In 2008.

Compound that with an archlinux policy of having reporters go upstream themselves, yet said reporter having no desire whatsoever to maintain accounts on, let's say,

[rene@e600 ~]$ pacman -Q | wc -l
791

... 500 or so different bugzilla's, probably in half of which the tried and tested open source development methodology of having bugreports simmer and rot for years on end anyway is active -- and I thought I'd in this case be content with my own solution of telling systemd-tmpfiles to just stay out off /run/user/*. Don't really know why I'd want that thing cleaning up anything anyway, after all.

But thanks for the attention. Your systemd tmpfiled.d exclusion file will (as you say in it) not help with the error message as reported on the archlinux report, and also in the context of your /etc/fuse.conf remark, and referring to comment 25 here, this seems to otherwise firmly be a fuse issue.

If "fuse" is what you meant with "upstream", then I'd hope you'd take this report there because it's much more potentially effective to have things like this reported by an important downstream user such as gvfs then by random enduser N+1.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/72.