Phillip Susi <[EMAIL PROTECTED]> 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 -- ~/.gvfs causes various errors https://bugs.launchpad.net/bugs/225361 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
