Comment 48 for bug 225361

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