After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 534284 - Root user can not access .gvfs
Root user can not access .gvfs
Status: RESOLVED NOTGNOME
Product: gvfs
Classification: Core
Component: general
0.2.x
Other All
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2008-05-22 02:49 UTC by Peng Huang
Modified: 2008-11-13 16:44 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Peng Huang 2008-05-22 02:49:46 UTC
Please describe the problem:
I use Archive Mounter to mount an Fedora 9 ISO dvd image in .gvfs/ folder. And use sudo rpm -ivh xxx.rpm to install some rpms. But failed with output:
error: open of xxxx.rpm failed: Permission denied.

Steps to reproduce:
1. Right click an ISO image file, and client open with "archive mounter"
2. Open term and go to some directory.
3. sudo rpm -ivh some rpm in the directory.



Actual results:
error: open of xxxx.rpm failed: Permission denied.

Expected results:
install the rpm successfully

Does this happen every time?
every time

Other information:
root user can not access .gvfs and its sub folders too.
Comment 1 David Zeuthen (not reading bugmail) 2008-05-22 21:12:10 UTC
IIRC, this is a limitation in FUSE itself... though perhaps it would be useful to allow this for root too.
Comment 2 Peng Huang 2008-05-23 03:02:17 UTC
It is useful. I think at least, gvfs or fuse should provide a way to configure the privilege for a mount point.
Comment 3 Ralph Corderoy 2008-05-23 09:44:40 UTC
For ~/.gvfs to not follow normal Unix semantics is a major pain.  As root, one can normally tar up a user's home directory, perhaps as part of a daily backup regime, without problems.  That's the point of running it as root.  Since the introduction of ~/.gvfs:

    $ sudo tar cf /dev/null .gvfs .bash_profile
    tar: .gvfs: Cannot stat: Permission denied
    tar: Error exit delayed from previous errors
    $ echo $?
    2
    $

So checking the exit status of tar for any backups problems now fails.  Every day.
Comment 4 Ralph Corderoy 2008-07-13 08:05:01 UTC
I assume that FUSE's allow_users and allow_root options aren't being
considered because they'd allow a plain user to DoS root. However, isn't a
plain user already allowed to plug in a USB flash drive with a
filesystem on it and have the system mount that? Do all filesystems
rigorously detect hierarchy loops, etc., caused by a malicious user
tweaking the filesystem's structures manually before the system kindly
mounting it for them; something normally only root could do?
Comment 5 Jorge Luis Gonzalez 2008-08-04 14:01:06 UTC
gvfs and gvfs-fuse  0.2.5-0ubuntu2
GNOME 1:2.20.2.2
Linux 2.6.24-19-generic
rsync 2.6.9-6ubuntu2

I maintain backups using dirvish, which writes sequential images using rsync.  Dirvish is set up to back up parts of my root partition and my home partition to a third partition.

Upon normal login to a GNOME desktop, ~/.gvfs has the following permissions:

jorge@satyr:~$ ls -ld .gvfs
dr-x------ 2 jorge jorge 0 2008-08-01 18:37 .gvfs

When dirvish (as root) attempts to back up my home partition with ~/.gvfs in the
preceding condition, it fails with the following rsync error:

rsync: readlink "/home/jorge/.gvfs" failed: Permission denied (13)
rsync error: some files could not be transferred (code 23) at main.c(977) [sender=2.6.9]

In order to run rsync on my home partition, I source a script from ~/.profile that loops the following:

/bin/fusermount -zu $HOME/.gvfs
/usr/lib/gvfs/gvfs-fuse-daemon $HOME/.gvfs

That gives me a directory with the following permissions:

jorge@satyr:~$ ls -ld .gvfs
drwx------ 2 jorge jorge 4096 2008-07-26 22:11 .gvfs

With ~/.gvfs so constituted, rsync successfully backs up my /home partition, and dirvish terminates with 0.  (Notice the weird timestamps on the directory listings.)

I'm not experiencing any other problems related to .gvfs, but this one seems relatively serious to me because it breaks an essential administration tool.
Comment 6 Alexander Larsson 2008-09-25 10:28:05 UTC
This is all unfortunate, but its a decision that has been taken by the fuse people at the kernel level (user others than the one who mounted the fs can't access it, including root) and there is nothing we can do about it.
Comment 7 Ron Yorston 2008-09-25 10:35:50 UTC
Of course you can do something about it:  you can choose not to use FUSE.
Comment 8 Ralph Corderoy 2008-09-25 11:53:05 UTC
Hi Alexander Larsson, what about FUSE's allow_users and allow_root options?  Could they help?  See my original comment above, http://bugzilla.gnome.org/show_bug.cgi?id=534284#c4
Comment 9 Alexander Larsson 2008-09-25 12:44:41 UTC
allow_root doesn't seem supported anymore, but allow_other might work. Can any user mount a filesystem with this though? I think its a security risk as you could e.g. fool a backup application to recurse into an unterminating hierarchy.
Comment 10 Phillip Susi 2008-11-03 18:45:25 UTC
While the problem of root accessing the .gvfs mount point is expected and will not be changed, the fact is that having .gvfs mounted in the user's home directory causes a number of errors for a number of people using a number of tools. I do not think there is any reason it needs to be mounted in the user's home directory, so perhaps moving the mount point to /tmp or /var/run would alleviate the issues people are having.

I suggest retitling this bug and returning the status to new until it can be decided whether .gvfs should be mounted somewhere else.
Comment 11 Matthias Clasen 2008-11-03 19:58:39 UTC
(In reply to comment #7)
> Of course you can do something about it:  you can choose not to use FUSE.
> 

See GIO_DISABLE_FUSE for that:

http://library.gnome.org/devel/gio/stable/ch03.html
Comment 12 Nikolaus 2008-11-13 16:44:26 UTC
Since this problem can clearly be solved in gvfs and I am not able to reopen this bug, I have submitted a new bug 560658.