Bug 211207
| Summary: | /net autofs directory is not accessible | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tomasz Kepczynski <tomek> | ||||||
| Component: | kernel | Assignee: | Ian Kent <ikent> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> | ||||||
| Severity: | urgent | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 5 | CC: | davej, dhowells, dwalsh, jmoyer, wtogami | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | autofs-4.1.4-29+2.6.17-1.2187_FC5 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2006-11-14 03:59:28 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 216180 | ||||||||
| Attachments: |
|
||||||||
Dan, sounds like a policy issue, right? (In reply to comment #1) > Dan, sounds like a policy issue, right? I'm afraid not. Assuming that this is the result of recent kernel patches (I didn't think they would show up yet) then the return from a mkdir call on an NFS directory returns EACCESS before it returns EEXIST on an existing directort. autofs needs to know if the directory exists and so this results in an error. I've already spent time on this and I'm about to again. Note that the result of this semantic change will mean that if a mountpoint directory on a remotely mounted filesystem does not already exist the mount will fail as creating such directories is considered to be a security risk. Tomasz are the directories, /net/triss/nfs/home etc. themselves within an NFS mount? Do the mount point directories, if they are located within an NFS mounted filesystem, already exist within that filesystem? Ian The server is configured as follows: /etc/exports: /nfs 192.168.253.0/24(rw,insecure,no_subtree_check,sync,no_root_squash,nohide,fsid=0) /nfs/home 192.168.253.0/24(rw,insecure,no_subtree_check,sync,no_root_squash,nohide,mp) /nfs/install 192.168.253.0/24(rw,insecure,no_subtree_check,sync,no_root_squash,nohide,mp) ls -l /nfs: triss:~> ls -l /nfs/ razem 16 drwxr-xr-x 7 root root 4096 kwi 16 2006 home drwxrwxrwt 5 root root 4096 kwi 8 2006 install and /etc/fstab: # This file is edited by fstab-sync - see 'man fstab-sync' for details LABEL=/boot /boot ext3 user_xattr,acl 1 2 /dev/triss/CENTOS / ext3 user_xattr,acl 1 1 /dev/triss/VAR /var ext3 user_xattr,acl 1 2 /dev/triss/HOME /nfs/home ext3 user_xattr,acl 1 2 /dev/triss/SWAP swap swap defaults 0 0 /dev/triss/TMP /tmp ext3 user_xattr,acl 1 2 /dev/triss/INSTALL /nfs/install ext3 user_xattr,acl 1 2 /dev/triss/VMWARE /var/lib/vmware/Virtual\040Machines ext3 user_xattr,acl 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs size=64M 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 The server is on CENTOS 4.4 with: kernel-2.6.9-42.0.2.EL nfs-utils-1.0.6-70.EL4 (In reply to comment #3) > The server is configured as follows: > > /etc/exports: > /nfs > 192.168.253.0/24(rw,insecure,no_subtree_check,sync,no_root_squash,nohide,fsid=0) > /nfs/home > 192.168.253.0/24(rw,insecure,no_subtree_check,sync,no_root_squash,nohide,mp) > /nfs/install > 192.168.253.0/24(rw,insecure,no_subtree_check,sync,no_root_squash,nohide,mp) OK. So that's a yes and a yes. Then I'll continue with the requirement that mount point directories on a remote share must exist. I'm working on fixing this now. It's gonna take a while I think. How longs "a while"? Good question. An initial version might be done by tomorrow but probably won't be done by tonight (my time) or I'll have a better idea of how long "a while" is. Ian Created attachment 138773 [details] Handle incorrectly null dentries created by autofs when permission was denied This is fixed upstream by this change: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fd6840714d9cf6e93f1d42b904860a94df316b85 *** This bug has been marked as a duplicate of 211206 *** Great we have the kernel patch part of this bug but I'm reopening this as I still need to deal with the user space mkdir return change. (In reply to comment #4) > (In reply to comment #3) > > The server is configured as follows: > > > > /etc/exports: > > /nfs > > 192.168.253.0/24(rw,insecure,no_subtree_check,sync,no_root_squash,nohide,fsid=0) > > /nfs/home > > 192.168.253.0/24(rw,insecure,no_subtree_check,sync,no_root_squash,nohide,mp) > > /nfs/install > > 192.168.253.0/24(rw,insecure,no_subtree_check,sync,no_root_squash,nohide,mp) I'm still a little concerned about this. First, I originally thought this error woukd only show up if the root_squash option was specified. So I'm not sure that my proposed solution will work. What is your expectation of how autofs should handle the nfs4 xdev mounts you have here, given that nfs will mount them and then autofs will then also try to mount them? As far as I can tell there is no way to identify nfs4 xdev exports from any other export. > I'm working on fixing this now. > It's gonna take a while I think. > > How longs "a while"? > Good question. An initial version might be done by tomorrow > but probably won't be done by tonight (my time) or I'll > have a better idea of how long "a while" is. Please give the patch below a try. > > Ian > Created attachment 139096 [details]
autofs-4.1.4-29 patch to deal with changed semantics of mkdir
> What is your expectation of how autofs should handle the > nfs4 xdev mounts you have here, given that nfs will mount > them and then autofs will then also try to mount them? As > far as I can tell there is no way to identify nfs4 xdev > exports from any other export. Well, I am not going to pretend I fully understand you question because I don't. I can only tell you, that all remote mounts on nfs client are version 3 and all are done by autofs. I would expect that regardless of means used (ie. nfs or nfs4 or manually/fstab or automatic mounts) I should be able to mount any exported direcotry as many times as I want. For the patch - it works. I used kernel 2.6.18-1.2200.fc5 and applied patch to autofs-4.1.4-29.src.rpm. I haven't tried kernel patch from bug #211206 and I haven't checked your patch against older kernels for any regression. (In reply to comment #10) > > What is your expectation of how autofs should handle the > > nfs4 xdev mounts you have here, given that nfs will mount > > them and then autofs will then also try to mount them? As > > far as I can tell there is no way to identify nfs4 xdev > > exports from any other export. > > Well, I am not going to pretend I fully understand you question > because I don't. I can only tell you, that all remote mounts > on nfs client are version 3 and all are done by autofs. > I would expect that regardless of means used (ie. nfs or nfs4 > or manually/fstab or automatic mounts) I should be able to mount > any exported direcotry as many times as I want. What I'm curious about is, when you set fsid=0 on the root export and set subordinate exports "nohide" the kernel will mount these upon access. I'm wondering what will happen when autofs also mounts them as there's no way for autofs to tell an export is marked "nohide". A bit out of scope for this bug really. > > For the patch - it works. I used kernel 2.6.18-1.2200.fc5 and > applied patch to autofs-4.1.4-29.src.rpm. I haven't tried > kernel patch from bug #211206 and I haven't checked your patch > against older kernels for any regression. > Thanks for the feedback. I'll send out an update after a bit more testing. I don't think you need to worry about the kernel patch. It addresses another issue that is seen as corruption within the NFS directory following an automount. Your setup doesn't appear to be vulnerable to this. As far as older kernels go the patch hopefully will work as expected. I'll test it out some more. Ian As for kernel 2.6.17-1.2187_FC5 I can confirm that your patch does work. |
Description of problem: /net autofs directory is not accessible Version-Release number of selected component (if applicable): kernel-2.6.18-1.2200.fc5 How reproducible: always Steps to Reproduce: I tried to access subdirectories of /net/triss/nfs/ and they are inaccessible. /var/log/messages lists: Oct 17 22:42:12 geralt automount[12149]: mount(nfs): mkdir_path /net/triss/nfs/h ome failed: Permission denied Oct 17 22:42:12 geralt automount[12149]: mount(nfs): mkdir_path /net/triss/nfs/i nstall failed: Permission denied ausearch -x automount shows: ---- time->Tue Oct 17 22:42:12 2006 type=SYSCALL msg=audit(1161117732.327:161): arch=c000003e syscall=83 success=no exit=-13 a0=7fff6e268230 a1=16d a2=5 a3=7fff6e26823e items=0 ppid=4316 pid=12149 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm= "automount" exe="/usr/sbin/automount" subj=root:system_r:automount_t:s0 key=(nul l) type=AVC msg=audit(1161117732.327:161): avc: denied { write } for pid=12149 c omm="automount" name="" dev=0:19 ino=327699 scontext=root:system_r:automount_t:s 0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir ---- time->Tue Oct 17 22:42:12 2006 type=SYSCALL msg=audit(1161117732.331:162): arch=c000003e syscall=83 success=no exit=-13 a0=7fff6e268200 a1=16d a2=8 a3=7fff6e26820e items=0 ppid=4316 pid=12149 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm= "automount" exe="/usr/sbin/automount" subj=root:system_r:automount_t:s0 key=(nul l) type=AVC msg=audit(1161117732.331:162): avc: denied { write } for pid=12149 c omm="automount" name="" dev=0:19 ino=327699 scontext=root:system_r:automount_t:s 0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir I guess this is selinux related problem, as it is gone when enforcing is disabled. I file it on a kernel as this seems to be the trigger (I've just updated it), and selinux was not recently updated. Maybe CacheFS is a problem here??? Actual results: Cannot access all exported directories. Expected results: Can access all exported directories. Additional info: One of the directories inaccessible under /net is mounted under /home (using automounter and nis map) and works fine.