Ubuntu

.gvfs can't be stat'd by root causing backup tools to fail

Reported by Thomas R. on 2008-05-01
332
This bug affects 53 people
Affects Status Importance Assigned to Milestone
gvfs
Confirmed
Medium
gvfs (ALT Linux)
Confirmed
Medium
gvfs (Ubuntu)
Medium
Ubuntu Desktop Bugs

Bug Description

Problem
=======
For security reasons ( possible DoS ), other users (esp. root) cannot access a fuse filesystem, and not even stat the mountpoint:

    $ sudo stat .gvfs
    stat: cannot stat `.gvfs': Permission denied
    $ sudo ls -la
    ls: cannot access .gvfs: Permission denied
    d????????? ? ? ? ? ? .gvfs

This means "rsync --one-file-system" (and similar options for find, tar...) cannot know this is a different file system they actually want to exclude, and fail on the permission denied error.

Please note that it is GOOD AND CORRECT that root cannot copy the .gvfs directory. The real problem is that the stat fails.

Workarounds
===========
* bind-mount the file system you want to backup beforehand (see comment #67)

See also
=======
* Excellent description of the problem in bug 227724
* fuse-devel mailing list saying this will all be solved someday using "private namespaces"
http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/3497/focus=3502
http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/7169/focus=7236
http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/6197 (no answer at all)
* Kernel documentation explaing the DoS
http://www.kernel.org/doc/Documentation/filesystems/fuse.txt

Thomas R. (pumbaa80) wrote :

> drwx------ 2 wg wg 4096 2008-04-25 23:12 /home/user/.gvfs

I'm sorry, I forgot to replace "wg" (the real user name) by "user" for readability:

drwx------ 2 user user 4096 2008-04-25 23:12 /home/user/.gvfs

Thomas Nybergh (apecat) wrote :

I'm experiencing a similar problem.

I did a clean install of 8.04 (32 bit, alternate installer) without overwriting my /home. After the install, I created a user and changed ownership of the old /home/thomas, but when I was about to remove parts of my settings files i encountered permission denied for .gvfs

root@anansi:/home/thomas# whoami
root
root@anansi:/home/thomas# ls .gvfs
ls: cannot access .gvfs: Permission denied

"ls -la ~thomas" shows the following on the row for the .gvfs directory
d????????? ? ? ? ? ? .gvfs

This bug should clearly be confirmed. As well as Thomas Nybergh spotting the same problem, I also raised a duplicate, bug #227724.

Changed in gvfs:
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

there is a bug about the issue on http://bugzilla.gnome.org/show_bug.cgi?id=534284

Changed in gvfs:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: Confirmed → Triaged
Changed in gvfs:
status: Unknown → New

I'd argue that, based on https://wiki.ubuntu.com/Bugs/Importance, this bug's Importance should be Medium. As described in the duplicate I raised, things like automatically checking the success of a daily tar(1) now fails because it always exits with a non-zero status instead of only rarely:

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.

I'd argue tar is pretty core and it's having a medium or severe impact, as outlined under Medium.

Sebastien Bacher (seb128) wrote :

the permission issue is a fuse one, not really due to gvfs, the mounts could be using a different directory though

Changed in gvfs:
importance: Low → Medium
Sebastien Bacher (seb128) wrote :

discussing the setting is not really useful too, setting to medium to avoid random comment but the issue is a manpower one mainly and the change is not going to make a real difference there if nobody starts working on the issue

Craig Maloney (craig-decafbad) wrote :

Is there a particular package that is causing this error to occur, and if so, is it possible to remove this package without seriously hampering the user experience? I'm finding it's cropping up more and more in my daily activities, and I want to get rid of it.

Chris Hines (c-hines) wrote :

I am by no means an expert in development, but I've been getting around this by adding --exclude "/home/.../.gvfs". It's worked, although it's a pain to backup more than one home account at a time. I'm not sure if this is relevant at all to the correction of this bug.

  • unnamed Edit (1.2 KiB, text/html; charset=ISO-8859-1)

what about --exclude=~/.gvfs ?

2008/6/5 Chris Hines <email address hidden>:

> I am by no means an expert in development, but I've been getting around
> this by adding --exclude "/home/.../.gvfs". It's worked, although it's a
> pain to backup more than one home account at a time. I'm not sure if
> this is relevant at all to the correction of this bug.
>
> --
> Superuser cannot access ~/.gvfs folder when mounted
> https://bugs.launchpad.net/bugs/225361
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
http://stephanvaningen.net
<email address hidden>
I am a happy www.ubuntu.com user
--

> what about --exclude=~/.gvfs ?

I don't think most shells will expand the tilde when it's not at the
start of a word like that.

    $ echo --exclude=~/foo
    --exclude=~/foo
    $

The problem here isn't that the issue can't be worked around, typically
adding an --exclude or several as Chris Hines points out, but that it
shouldn't be neccessary; the basic Unix premise that root can stat the
inode has been broken.

I assume that FUSE's allow_users and allow_root options aren't being
used 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?

It appears the latest round of updates has fixed this. Please check to see if you're still having this issue.

This is an up to date 8.04 i386.

    $ sudo strace -e trace=lstat64 stat /home/ralph/.gvfs
    lstat64("/home/ralph/.gvfs", 0xbfe8be54) = -1 EACCES (Permission denied)
    stat: cannot stat `/home/ralph/.gvfs': Permission denied
    Process 30706 detached
    $

I think the problem still exists.

Here's the results on my system:

craig@lister:~$ sudo strace -e trace=lstat64 stat /home/craig/.gvfs
[sudo] password for craig:
lstat64("/home/craig/.gvfs", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
  File: `/home/craig/.gvfs'
  Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 805h/2053d Inode: 12222947 Links: 2
Access: (0700/drwx------) Uid: ( 1000/ craig) Gid: ( 1000/ craig)
Access: 2008-06-13 01:01:01.000000000 -0400
Modify: 2008-05-24 07:18:23.000000000 -0400
Change: 2008-05-24 07:18:23.000000000 -0400
Process 26872 detached
craig@lister:~$ uname -a
Linux lister 2.6.24-18-generic #1 SMP Wed May 28 20:27:26 UTC 2008 i686 GNU/Linux
craig@lister:~$

Interesting. There's a couple of differences in the .gvfs inode between the two of us. Your perms are 0700, mine are 0500. Your access time is today but your modify and change aren't, all three of mine are the same value. Do you have anything mounted on .gvfs, if not, perhaps it's just a normal directory now in your system? Anyway, I am up to date with the 8.04 packages and I still get the problem.

pt123 (pt123) wrote :

Me too same problem as Ralph

sudo strace -e trace=lstat64 stat /home/pt123/.gvfs/
[sudo] password for pt123:
lstat64("/home/pt123/.gvfs/", 0xbffba7b4) = -1 EACCES (Permission denied)
stat: cannot stat `/home/pt123/.gvfs/': Permission denied
Process 8670 detached

Linux 2.6.24-18-generic #1 SMP Wed May 28 20:27:26 UTC 2008 i686 GNU/Linux

Also before when tar-ing adding an exlude for .gvfs folder still threw an error ( if I recall correctly), but now it doesn't. :)

Sebastien Bacher (seb128) wrote :

could people stop adding comments to this bug? the bug has been marked triaged and no confirmation is required, you are just mail spamming other subscribers now

It may have originally been confirmed and triaged but surely it's normal
to respond to a `It looks like it's recently been fixed, please check'
request. To not do so might mislead people into thinking it has indeed
been fixed. That is not spamming.

there is no reason why the issue should have changed since gvfs didn't change recently and one person replying is enough in any case, no need to have several comments stating the same thing

Craig Maloney (craig-decafbad) wrote :

I'm sorry my comment was regarded as spam. I woke up that morning and noted that .gvfs was no longer causing me any exceptions in my nightly rsync, where it had generated issues every night since I upgraded to hardy. I don't know what changed, but felt it might be important to tell someone that whatever they did, it seemed to take care of the issue for me.

Sebastien Bacher (seb128) wrote :

that's no issue but 8 comments have been added in a few days now which means 8 mails sent to whoever is subscribed to the bug

Craig Maloney (craig-decafbad) wrote :

Apparently I didn't have any .gvfs filesystems mounted, because now that I have VirtualBox-OSE-modules installed, it's causing the .gvfs permission errors all over again. Sorry for the confusion!

Sebastien Bacher (seb128) wrote :

upstream closed the bug as not a gvfs one

"

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

Changed in gvfs:
status: Triaged → Invalid
Changed in gvfs:
status: New → Invalid
gwi (george-willegers) wrote :

That ("user others than the one who mounted the fs can't access it, including root") is not completely true.
I have two systems (not connected to eachother), both running Ubuntu 8.04.

On one of them I have one user, created during install, and member of sudoers. On this system I use a script that uses sudo rsync to create backups. I never get errors.

On the other system I have three users, let's call them A, B and C. A was created during install, and is member of sudoers (and as such is comparable to the only user on the first system). Here I am using the same backup script, and here I always get permission denied errors accessing /home/A/.gvfs.
I do NOT get errors when the script tries to access /home/B/.gvfs or /home/C/.gvfs!
In fact, user A can do a sudo -i, and then cd to /home/B/.gvfs, but not cd to his own /home/A/.gvfs.

So it looks like there IS a bug somewhere, and it would be nice to see it fixed.

In my opinion, this doesn't reall give enough information to confirm
that the behaviour isn't down to user error. For example, on the second
machine the cut-and-pasted output of

    for u in A B C; do ls -ld /home/$u{,/.gvfs}; df /home/$u/.gvfs; id $u; done

would be useful.

Hi all,
 This is a Hardy updated/upgraded machine. I don't have anything of samba. The only thing I have is ntfs3-g driver which uses fuse, I think that's why I have .gvfs

$ ls -ld .gvfs
dr-x------ 2 shirish shirish 0 2008-10-23 21:08 .gvfs

Ralph, this is what it shows on my system (using the logged in user)

ls -ld /home/$u{,/.gvfs}
ls: cannot access /home//.gvfs: No such file or directory
drwxr-xr-x 4 root root 4096 2008-10-20 00:15 /home/

df /home/$u/.gvfs
df: `/home//.gvfs': No such file or directory
df: no file systems processed

id $u gives
uid=1000(shirish) gid=1000(shirish) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),107(fuse),109(lpadmin),115(admin),117(pulse-access),118(pulse-rt),121(netdev),1000(shirish)

Anything worthwhile therein?

Shirish Agarwal (shirishag75) wrote :

I ran into this bug while trying to accomplish

sudo ls -l .* >> user.txt
ls: cannot access .gvfs: Permission denied

if you see any error with this please lemme know.

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.

Changed in gvfs:
status: Invalid → Triaged

Philip,
 Thanx. I would be happy with that outcome :)
--
          Regards,
          Shirish Agarwal
  This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17

If it is not necessary that each user has its own ./gvfs, than that indeed
is a good workaround

2008/11/4 Shirish Agarwal <email address hidden>

> Philip,
> Thanx. I would be happy with that outcome :)
> --
> Regards,
> Shirish Agarwal
> This email is licensed under
> http://creativecommons.org/licenses/by-nc/3.0/
> http://flossexperiences.wordpress.com
> 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17
>
> --
> ~/.gvfs causes various errors
> https://bugs.launchpad.net/bugs/225361
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Even if each user has his/her own .gvfs, it can still be mounted as /tmp/gvfs-username! A lot of gnome utilities already do that, so it won't be a big deal. And of course, there should be no security issue in using /tmp, since even root can't access gvfs mounts! ;)

That is indeed possible, didn't see that one coming ;)

2008/11/4 Sameer D. Sahasrabuddhe <email address hidden>

>
> Even if each user has his/her own .gvfs, it can still be mounted as
> /tmp/gvfs-username! A lot of gnome utilities already do that, so it won't be
> a big deal. And of course, there should be no security issue in using /tmp,
> since even root can't access gvfs mounts! ;)
>
> --
> ~/.gvfs causes various errors
> https://bugs.launchpad.net/bugs/225361
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Shirish Agarwal (shirishag75) wrote :

Hi all,
 This is all good news, I just hope somebody takes ownership of the
bug and we, the poor users have some sort of solution by the end of
jaunty cycle.
--
          Regards,
          Shirish Agarwal
  This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17

Your best chance of making that happen is probably to discuss your ideas with the upstream developers.

Phillip Susi (psusi) wrote :

I added my comments to the gnome bugzilla, but it is still marked as invalid and I can't change it. Hopefully someone will change it back to new until the idea is reviewed, or maybe I should file a new bug in their bugzilla?

The location where .gvfs is mounted is likely an easily configurable parameter that Ubuntu could customize, but it will take someone more familiar with the component to speak to that with authority.

Chris Coulson (chrisccoulson) wrote :

Philip - Yes, I think your best chance is to open a low importance bug on the bugzilla, as the idea that is being proposed is separate from the original bug report about the root user not having access to ~/.gvfs

S B (seuzy8) wrote :

How would I go about doing mounting my gvfs under /tmp? This bug is causing me and at least several others to lose audio from our computers altogether. I would like to know how to implement the workaround for now. Would there be any side effects to mounting the gvfs in the /tmp folder? Thanks.

> Even if each user has his/her own .gvfs, it can still be mounted as /tmp/gvfs-username! A lot of gnome utilities already do > that, so it won't be a big deal. And of course, there should be no security issue in using /tmp, since even root can't access > gvfs mounts! ;)

Just to be clear, mounting .gvfs somewhere other than $HOME doesn't solve the problem this bug's covering IMO, which is that the filesystem breaks the Unix norm that root can stat anything.

Ralph Corderoy wrote:
> Just to be clear, mounting .gvfs somewhere other than $HOME doesn't
> solve the problem this bug's covering IMO, which is that the filesystem
> breaks the Unix norm that root can stat anything.

That is really just a contributing factor, not the problem. The problem
is that people are having utilities fail when they run into .gvfs
because root can't access it ( and this is by design, not a bug ). The
utilities in question shouldn't be messing with .gvfs in the first
place, so a simple solution is to move it somewhere they aren't going to
run into it.

I am not going to argue about the definition of a bug. But why was this particular design chosen? It seems to me that it only causes the problems described above and does not have any positive effects.

S B (seuzy8) wrote :

So, correct me if I'm wrong. There is no work around right now?

I run into this bug when I run the command:
$ sudo alsa reload

And I really need to use this command, because the audio on my system is flat out not working. If there's any way to fix this, I'd really like to know about it.

Phillip Susi wrote:
> That is really just a contributing factor, not the problem. The
> problem is that people are having utilities fail when they run into
> .gvfs because root can't access it ( and this is by design, not a bug
> ).

It is a bug in that, under Unix, by design, that should *never* happen
to a process running as root.

> The utilities in question shouldn't be messing with .gvfs in the first
> place, so a simple solution is to move it somewhere they aren't going
> to run into it.

Sorry, that's not possible. As root, it's entirely valid, and not
uncommon, for me to run `find / ...' which will descend and find .gvfs
wherever to decide to move it to.

Nikolaus Rath and S B, take a look at my earlier comment
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/225361/comments/11 I
understand this configuration of FUSE has been chosen because of
security concerns, as opposed to using its allow_users or allow_root
options. However, I'm not sure those concerns remain valid given Ubuntu
automatically mounts the filesystems on a USB flash drive I insert, and
I doubt every piece of filesystem code in the kernel is robust against
maliciously concocted corrupt filesystems.

Nikolaus Rath (nikratio) wrote :

Ralph Corderoy <email address hidden> writes:
> Nikolaus Rath and S B, take a look at my earlier comment
> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/225361/comments/11 I
> understand this configuration of FUSE has been chosen because of
> security concerns, as opposed to using its allow_users or allow_root
> options.

This is not a valid concern. In Ubuntu, allow_root is by default
enabled in /etc/fuse.conf. So even if gvfs does not use --allow-root,
a malicious user can simply mount a filesystem of his choice manually
and with --allow-root.

If --allow-root poses a security risk, it has to be disabled in
/etc/fuse.conf and not in individual applications that happen to call
fuse.

Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

Nikolaus wrote:
> > https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/225361/comments/11
> > I understand this configuration of FUSE has been chosen because of
> > security concerns, as opposed to using its allow_users or allow_root
> > options.
>
> This is not a valid concern. In Ubuntu, allow_root is by default
> enabled in /etc/fuse.conf.

In my untouched 8.04 /etc/fuse.conf, both mount_max and user_allow_other
are commented out, meaning the file has no active options.

> So even if gvfs does not use --allow-root, a malicious user can simply
> mount a filesystem of his choice manually and with --allow-root.

It's my understanding that Ubuntu have set up automounting of user
filesystems (non-FUSE ones) so a malicious user can have root mount
their concocted filesystem anyway, so I'm not sure what the current
troublesome, non-Unix, FUSE configuration is protecting us from?

Nikolaus Rath (nikratio) wrote :

Ralph Corderoy <email address hidden> writes:
> Nikolaus wrote:
>> > https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/225361/comments/11
>> > I understand this configuration of FUSE has been chosen because of
>> > security concerns, as opposed to using its allow_users or allow_root
>> > options.
>>
>> This is not a valid concern. In Ubuntu, allow_root is by default
>> enabled in /etc/fuse.conf.
>
> In my untouched 8.04 /etc/fuse.conf, both mount_max and
> user_allow_other are commented out, meaning the file has no active
> options.

Hmm. I'm running 8.04 as well, and here it is enabled. I don't
remember changing it either. However, this is not a fresh install but
has been upgraded several times, so maybe the setting survived from an
older release.

>> So even if gvfs does not use --allow-root, a malicious user can simply
>> mount a filesystem of his choice manually and with --allow-root.
>
> It's my understanding that Ubuntu have set up automounting of user
> filesystems (non-FUSE ones) so a malicious user can have root mount
> their concocted filesystem anyway, so I'm not sure what the current
> troublesome, non-Unix, FUSE configuration is protecting us from?

Yes, I don't see any point in that either.

Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

fuse-utils version 2.7.2-1ubuntu2 has a debian/fuse.conf that's
identical to my /etc one, i.e. everything commented out, so perhaps
you're right about the survival from an older release.

Phillip Susi (psusi) wrote :

Ralph Corderoy wrote:
> It is a bug in that, under Unix, by design, that should *never* happen
> to a process running as root.

Maybe 20 years ago, but these days being root does NOT mean you can do
anything ( take a look at SELinux ). Heck, even 20 years ago root ran
into issues like this with NFS. .gvfs is working as designed.

> Sorry, that's not possible. As root, it's entirely valid, and not
> uncommon, for me to run `find / ...' which will descend and find .gvfs
> wherever to decide to move it to.

And you need to deal with access denied errors.

> Nikolaus Rath and S B, take a look at my earlier comment
> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/225361/comments/11 I
> understand this configuration of FUSE has been chosen because of
> security concerns, as opposed to using its allow_users or allow_root
> options. However, I'm not sure those concerns remain valid given Ubuntu
> automatically mounts the filesystems on a USB flash drive I insert, and
> I doubt every piece of filesystem code in the kernel is robust against
> maliciously concocted corrupt filesystems.

AFAIK, the allow_root option does not work because .gvfs requires the
kernel keyring for authentication. Same goes for ecryptfs mounted
~/private. Root can't access it because the process doesn't have the
decryption key on its keyring.

At the end of the day programs simply have to deal with access denied
errors, even when run as root. This bug was marked as invalid both here
and upstream because this point will not change.

Nikolaus Rath (nikratio) wrote :

Phillip Susi <email address hidden> writes:
> Ralph Corderoy wrote:
>> It is a bug in that, under Unix, by design, that should *never* happen
>> to a process running as root.
>
> Maybe 20 years ago, but these days being root does NOT mean you can do
> anything ( take a look at SELinux ). Heck, even 20 years ago root ran
> into issues like this with NFS. .gvfs is working as designed.

There is a difference between being able to impose specific
restrictions even on the root account (SELinux) and the root account
in general not being able to access all files in /home (as happening
with gvfs). In other words, using SELinux does not prevent you from
accessing /home/* (or any other directory) unless you chose to
*configure* it that way.

The fact that NFS has its bug is not a justification for not fixing
similar bugs in gvfs.

>> Nikolaus Rath and S B, take a look at my earlier comment
>> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/225361/comments/11 I
>> understand this configuration of FUSE has been chosen because of
>> security concerns, as opposed to using its allow_users or allow_root
>> options. However, I'm not sure those concerns remain valid given Ubuntu
>> automatically mounts the filesystems on a USB flash drive I insert, and
>> I doubt every piece of filesystem code in the kernel is robust against
>> maliciously concocted corrupt filesystems.
>
> AFAIK, the allow_root option does not work because .gvfs requires the
> kernel keyring for authentication.

I don't quite understand what you mean. In which way does the passing
of an option to the FUSE library effect authentication? gvfs will run
exactly the same way.

> Same goes for ecryptfs mounted
> ~/private. Root can't access it because the process doesn't have the
> decryption key on its keyring.

I don't know about ecryptfs, but a fuse filesystem does not need to
run as root in order for --allow-root to work (is this what you
assume?).

> At the end of the day programs simply have to deal with access
> denied errors, even when run as root. This bug was marked as invalid
> both here and upstream because this point will not change.

I would probably agree with you here. But the thing is that programs
don't get a simple access denied error. If I have rx permissions on a
directory, then I ought to be able to stat() everything in it. This
does not work if there is a fuse mounted .gvfs in there.

Changing the behavior to allowing root to stat() the directly (but not
granting read- or execute permissions) would probably also fix most of
the issues.

Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

Phillip Susi (psusi) wrote :

Nikolaus Rath wrote:
> There is a difference between being able to impose specific
> restrictions even on the root account (SELinux) and the root account
> in general not being able to access all files in /home (as happening
> with gvfs). In other words, using SELinux does not prevent you from
> accessing /home/* (or any other directory) unless you chose to
> *configure* it that way.

And neither does gvfs, nfs, or ecryptfs unless you choose to use them.

> The fact that NFS has its bug is not a justification for not fixing
> similar bugs in gvfs.

It isn't justification, and it isn't a bug. It is by design. NFS and
ecryptfs and SELinux are just other examples of areas where root is
denied access *BY DESIGN*.

> I don't quite understand what you mean. In which way does the passing
> of an option to the FUSE library effect authentication? gvfs will run
> exactly the same way.

I believe the gvfs uses the kernel keyring for authentication to remote
network resources and such, ergo simply being root can not grant you access.

> I don't know about ecryptfs, but a fuse filesystem does not need to
> run as root in order for --allow-root to work (is this what you
> assume?).

See above. In the case of ecryptfs everything requires a decryption key
stored in the kernel keyring to access. .gvfs maps local files, but
also contains other things like network resources which require
authentication that is not available to a root process that is not a
child of the interactively logged on user, so the process can not access
those files.

> I would probably agree with you here. But the thing is that programs
> don't get a simple access denied error. If I have rx permissions on a
> directory, then I ought to be able to stat() everything in it. This
> does not work if there is a fuse mounted .gvfs in there.
>
> Changing the behavior to allowing root to stat() the directly (but not
> granting read- or execute permissions) would probably also fix most of
> the issues.

Hrm.... it does seem like you should be able to stat the mount point
itself. How would this solve the problem though? find often complains
that it can't stat() temporary files that have been unlinked between the
readdir() call and the stat(). Any calling script should not be upset
by such errors.

On Monday 17 November 2008 18:44:18 Nikolaus Rath wrote:
> I don't know about ecryptfs, but a fuse filesystem does not need to
> run as root in order for --allow-root to work (is this what you
> assume?).

We are going of topic and discussing something that should be done on a ML and not on a BTS.
But since I use encfs (that uses fuse) I can tell you that root wont access the files, unless you mount the colume with --public, and you can only do that if you mount it as root.

--
BUGabundo :o)
(``-_-´´) http://LinuxNoDEI.BUGabundo.net && Ubuntu LoCoTeam Portugal http://ubuntu-pt.org
Linux user #443786 GPG key 1024D/A1784EBB

Phillip Susi <email address hidden> writes:
> [ Should root be able to access everything? ]

BUGabundu is right, this discussion probably belongs somewhere else.

So let my just state my main point again: using --allow-root does not
have any negative side effects and would prevent many applications
from needing fixing.

> I believe the gvfs uses the kernel keyring for authentication to
> remote network resources and such, ergo simply being root can not
> grant you access.

gvfs does not need to be root in order for --allow-root to work. So
this shouldn't be a problem.

>> Changing the behavior to allowing root to stat() the directly (but not
>> granting read- or execute permissions) would probably also fix most of
>> the issues.
>
> Hrm.... it does seem like you should be able to stat the mount point
> itself. How would this solve the problem though? find often
> complains that it can't stat() temporary files that have been
> unlinked between the readdir() call and the stat(). Any calling
> script should not be upset by such errors.

Yes, but here the situation is different: readdir() returns an entry
that cannot be stat()ed. In the above case, we simply have a race
condition between stat() and readdir(). But this does not belong here
either, so I will try to get this change into FUSE.

Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

Philip Susi wrote:

> Maybe 20 years ago, but these days being root does NOT mean you can do
> anything ( take a look at SELinux ). Heck, even 20 years ago root ran
> into issues like this with NFS. .gvfs is working as designed.

> At the end of the day programs simply have to deal with access denied
> errors, even when run as root. This bug was marked as invalid both here
> and upstream because this point will not change.

Thanks Philip, for taking a clear stand about this bug. A related message is <a href="">here</a>, although it's terse enough to border on being called rude. The problem right now is that nobody is putting this issue completely at rest. What does Ubuntu officially think? Is it time to file bugs for every tool that chokes on this problem? I was affected because rsync would exit with "I/O errors" and fail to delete any files. Should I file a bug saying rsync should know better?

http://mail.gnome.org/archives/gvfs-list/2008-November/msg00001.html

This link was meant to go in the previous message.

Phillip Susi (psusi) wrote :

If rsync errors out immediately because it gets an access denied error opening one source file, then yes, I'd say you should file a bug report against it. Well behaved tools, such as tar, print an error message and carry on with the rest of the files they CAN operate on.

Changed in gvfs:
status: Unknown → New
Changed in gvfs:
status: Invalid → Unknown

So, are we instead to raise a bug on every program and script that doesn't expect a brain-damaged response due to ~/.gvfs? And then expect the maintainers of those programs to work around the brain damage? E.g. `alsa force-reload' causes `lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/peter/.gvfs' to appear.

Nikolaus Rath (nikratio) wrote :

It is also possible to fix this on the FUSE side by changing the stat() behaviour. But this doesn't have a high priority right now, because an even cleaner behaviour will automatically come about with the introduction of private namespaces. See the discussion in http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/3497/focus=3502 and http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/7169/focus=7236

summary: - ~/.gvfs causes various errors
+ other users don't have access to .gvfs
Changed in gvfs:
status: Unknown → New

Same error on Suse 11.1, when I do
sudo find / -name "*wav" -path "/mnt" -prune
Then: find: `/home/peter/.gvfs': Permission non accordée

MountainX (dave-mountain) wrote :

FROM http://ubuntuforums.org/showthread.php?t=791693&highlight=.gvfs&page=2
"This is the official solution:
sudo aptitude reinstall gvfs gvfs-backends gvfs-bin gvfs-fuse libgvfscommon0"

Is that true?

Nikolaus Rath (nikratio) wrote :

No, that's not true. The above command only reinstalls the packages, so this won't change anything.

Xavier De Poorter (depx) wrote :

Hi, other users can't have access to .gvfs :

I tried to hack it directly in gvfs but i found in fuse code :

2005-07-07 Miklos Szeredi <email address hidden>

        * lib: don't allow both 'allow_other' and 'allow_root' options to
        be given

gvfs use libfuse2 so i hacked fuse :

diff fuse-2.7.4/kernel/ fuse-2.7.4-modified/kernel/
diff fuse-2.7.4/kernel/dir.c fuse-2.7.4-modified/kernel/dir.c
728a729,730
> return 1;
>
diff fuse-2.7.4/kernel/inode.c fuse-2.7.4-modified/kernel/inode.c
377a378,383
>
> switch (token) {
> default:
> d->flags |= FUSE_ALLOW_OTHER;
> }
>

be careful, it force the option allow_other for each fuse mount

and it works !

i done this trick to replace sftpdrive or webdrive (win32 + proprietary) by a virtual box + samba + "user friendly" nautilus gvfs on the office's win32 boxes

Changed in gvfs:
importance: Unknown → Medium
Changed in gvfs (ALT Linux):
importance: Unknown → Medium
Jochen Fahrner (jofa) wrote :

We are now on 10.10 Maverick and this bug still exists. I can't believe that!
I have over 20 years experience in unix systems, and believe me, if this bug is meant "by design", than this design is broken!
There should be nothing that root can't access on my own machine. There are some filesystems for accessing remote file systems (e.g. nfs), where you can define root acces as "nobody". This is for security reasons, because you don't always have control over user rigths on remote systems. But inside my own system, root should have access to everything.

And even if I have mounted filesystems where my root account has nobodys rights, then it should be possible to exclude them with rsyncs -x option (don't cross filesystem boundaries). This seems to be a second bug. Why does rsync try to include .gvfs with the -x option? If this is a mounted filesystem, it should be recognized as such.

rsync isn't trying to include .gvfs even with the -x option. It along with find(1), etc., has to be able to do some things with .gvfs to even work out it is the mount point of another filesystem and shouldn't be descended into further. Those things fail in a way that they never should with Unix semantics for root. You're just seeing other symptoms of the same underlying problem; FUSE's configuration not allowing root to do anything, as it normally can. But this bug report isn't the place for discussion, I suspect. I just wanted to clarify that there isn't a further bug.

This bug still exist in Lubuntu 11.04...

Jochen Fahrner (jofa) wrote :

Since this bug is 3 years old, I think this will never be fixed. :-(

dahias (wengahias) wrote :

Ubuntu 11.10 ... still there ...

nschoem (nschoem) wrote :

I have reproduced this bug when switching between different window managers (GNOME to Xfce).

Adam Wolfe Gordon (awg) wrote :

I've found a nice workaround for this, at least for the case where root is trying to backup /home.

Before performing the backup, do:

mount --bind /home /mnt/home-bind

Then, backup /mnt/home-bind instead of /home. The bind mount exposes only things on the filesystem mounted at /home, so you get a full backup of that, without the FUSE/gvfs problem getting in the way.

Fakher Oueslati (ftv-dev) wrote :

Here is a nicer workaround ;)

fusermount -u <path>/.gvfs

summary: - other users don't have access to .gvfs
+ .gvfs can't be stat'd by root causing backup tools to fail
description: updated
description: updated
Will Rouesnel (w-rouesnel) wrote :

On 12.10 this still appears to be an issue out of the box.

The biggest problem it causes is that it makes working with one's own system very frustrating, since you lose the ability to use any GVFS mounted filesystems between sudo'd nautilus windows (you have to drag to local machine, then drag to wherever one is working).

There desperately needs to be a configuration option for this.

Karma Dorje (taaroa) wrote :

this seems to me a blatant POSIX violation.
fuse aka userspace filesystem is a foreign thing for UNIX and, as we say, it is hopeless. Linus agrees [1].

[1] http://www.spinics.net/lists/linux-fsdevel/msg46078.html

Changed in gvfs:
status: New → Confirmed
Changed in gvfs (ALT Linux):
status: New → Confirmed
Martin Pitt (pitti) wrote :

~/.gvfs is not being used any more since we introduced proper $XDG_RUNTIME_DIR in Quantal. It's now in /run/user/ where it doesn't hurt.

Changed in gvfs (Ubuntu):
status: Triaged → Fix Released

So can rsync --one-file-system, find, etc., now stat the inode to know it's another filesystem and not attempt to descend?

dino99 (9d9) wrote :

related to #71 above:

sadly even with the latest RR, the 3.8.0.10 kernel was trying to update/read that oldish .gvfs file. So "leftover" file are still a real pain.

https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1148823

On 3/6/2013 6:28 AM, Ralph Corderoy wrote:
> So can rsync --one-file-system, find, etc., now stat the inode to know
> it's another filesystem and not attempt to descend?

No, so it is still a bug in the kernel, but at least it is now in a
location where rsync is never going to get to it unless you try to rsync
/run, which you would never do.

Jochen Fahrner (jofa) wrote :

I do a regularly backup of '/' and that includes /run. Why should I never do this?

Phillip Susi (psusi) wrote :

On 3/6/2013 10:40 AM, Jochen Fahrner wrote:
> I do a regularly backup of '/' and that includes /run. Why should I
> never do this?

Because /run is a tmpfs to contain only ephemeral runtime information.
If you back it up, you are backing up useless junk that won't even be
seen after the restore and just waste disk space since the tmpfs will be
mounted over it at boot. Your backups should use --one-file-system to
make sure they stay out of things like /run, /proc, /sys, /dev.

Calum Mackay (calum-mackay) wrote :

Normal practice would be to backup each filesystem separately, using e.g. rsync's -x option not to cross filesystem boundaries.

Jochen Fahrner (jofa) wrote :

I did not know that /run is a separate filesystem. According to question #72 and answer #74 I was assuming it is not.

Calum Mackay (calum-mackay) wrote :

The bug is that doing a stat on .gvfs as root causes an error, which upsets rsync et al.

When .gvfs was in your home dir, that means you would have problems backing up your homedir: rsync would fail when it got the stat error.

That bug is not fixed, but .gvfs has now been moved to /run, which is a separate filesystem, backed by tmpfs (i.e. virtual memory) which you would not normally be backing up.

So, the bug is still there, but you're now much less likely to find it causing you a problem.

Martin Pitt wrote:
> status: Triaged → Fix Released

So if this is considered the fix should we now raise bugs on all the user-space programs that are disgruntled to find root can't stat .gvfs as part of detecting it's a mount-point that shouldn't be crossed?

Those user-space programs already stop at /run - which is a tmpfs and can be stat'd. The issue is solved for all practical purposes that I am aware of.

Will Ubuntu 12.04 get an update to move the .gvfs folder away from the home directory, or will it be left in its current stable but broken state once again?

I don't think so. This is a big change for a low-impact bug, seehttps://wiki.ubuntu.com/StableReleaseUpdates#When . Upgrade if you want the fix.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Bug attachments

Remote bug watches

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