Comment 49 for bug 225361

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.