Description of problem: When a mount is specified explicitly as an NFS mount, but is on the local system, autofs automatically changes it to a bind mount. This is probably a good thing for performance purposes, but it has the nasty side effect of discarding security the squash_root that comes from an nfs mount. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. Add an entry like: /test/nfs /etc/auto.nfs-test to /etc/auto.master. 2. In auto.nfs-test add lines like: /a -fstype=nfs localhost:/test/a 3. Create a /test/a directory and make sure it is exported from the localhost. 4. Reload tho autofs configuration. 5. Activate the auto mount with the command: ls /test/nfs/a to activate the mount 6. As root try writing and reading files in /test/nfs/a. 7. Try: umount /test/nfs/a mount -t nfs localhost:/test/a /test/nfs/a 8. As root try writing and reading files in /test/nfs/a. Actual results: In step 6 we could read & write as root. In step 8 we could not. Expected results: Since -fstype=nfs was explicitly supplied, the security settings should be the same in both instances. Additional info:
(In reply to comment #0) > Description of problem: > > When a mount is specified explicitly as an NFS mount, but is on the local > system, autofs automatically changes it to a bind mount. This is probably a > good thing for performance purposes, but it has the nasty side effect of > discarding security the squash_root that comes from an nfs mount. And I'm fairly sure there are people who specify fstype=nfs and expect autofs to do a bind mount automatically if the filesystem is local. I don't think this is correct forum to discuss this. If you would like to argue your case then the autofs mailing list at http://linux.kernel.org/mailman/listinfo/autofs is the place for this. Ian
The problem is not necessarily that it does a bind mount instead of an NFS mount. In theory, that is a nice optimization. The problem is that security options are silently discarded. At minimum this should be noted in the manual page. If you do not feel this is necessary, feel free to close this bug, as it does not impact me. I just noticed the security problem, and was concerned some administrator might naively end-up with problems. But when I think about it, the whole point of squash_root is that someone may have root access on a different machine, but not on yours. If they are accessing the file system via a bind auto-mount, that logic no longer applies. So about the only case where this might have an effect is to somehow bypass SELinux restrictions on root access.
(In reply to comment #2) > The problem is not necessarily that it does a bind mount instead of an NFS > mount. In theory, that is a nice optimization. The problem is that security > options are silently discarded. At minimum this should be noted in the manual page. > > If you do not feel this is necessary, feel free to close this bug, as it does > not impact me. I just noticed the security problem, and was concerned some > administrator might naively end-up with problems. But when I think about it, > the whole point of squash_root is that someone may have root access on a > different machine, but not on yours. If they are accessing the file system via > a bind auto-mount, that logic no longer applies. So about the only case where > this might have an effect is to somehow bypass SELinux restrictions on root access. You've made a good point but I'd rather not change this. What I was saying above is that I'm pretty sure this is used (with the fstype given) and people expect the option to be overridden when the mount is local giving consistent map and file name space whether the mount is local or not. And yes, the root_squash really is for NFS filesystems and if your local and you have root then you don't need to bother with automounts to break things. Ian