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. -- ~/.gvfs causes various errors https://bugs.launchpad.net/bugs/225361 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is the registrant for gvfs. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
