Bug 211207 - /net autofs directory is not accessible
/net autofs directory is not accessible
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
x86_64 Linux
medium Severity urgent
: ---
: ---
Assigned To: Ian Kent
Brian Brock
: Reopened
Depends On:
Blocks: 216180
  Show dependency treegraph
 
Reported: 2006-10-17 16:52 EDT by Tomasz Kepczynski
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
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-13 22:59:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Handle incorrectly null dentries created by autofs when permission was denied (1.73 KB, patch)
2006-10-18 07:41 EDT, David Howells
no flags Details | Diff
autofs-4.1.4-29 patch to deal with changed semantics of mkdir (4.18 KB, patch)
2006-10-23 01:03 EDT, Ian Kent
no flags Details | Diff

  None (edit)
Description Tomasz Kepczynski 2006-10-17 16:52:36 EDT
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.
Comment 1 Jeffrey Moyer 2006-10-17 17:24:26 EDT
Dan, sounds like a policy issue, right?
Comment 2 Ian Kent 2006-10-17 21:43:06 EDT
(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
Comment 3 Tomasz Kepczynski 2006-10-18 00:44:24 EDT
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
Comment 4 Ian Kent 2006-10-18 05:37:37 EDT
(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
Comment 5 David Howells 2006-10-18 07:41:55 EDT
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
Comment 6 David Howells 2006-10-18 07:45:18 EDT

*** This bug has been marked as a duplicate of 211206 ***
Comment 7 Ian Kent 2006-10-18 08:03:07 EDT
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.
Comment 8 Ian Kent 2006-10-23 01:01:03 EDT
(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
> 

Comment 9 Ian Kent 2006-10-23 01:03:11 EDT
Created attachment 139096 [details]
autofs-4.1.4-29 patch to deal with changed semantics of mkdir
Comment 10 Tomasz Kepczynski 2006-10-23 11:57:28 EDT
> 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.
Comment 11 Ian Kent 2006-10-23 13:06:53 EDT
(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
Comment 12 Tomasz Kepczynski 2006-10-23 14:30:01 EDT
As for kernel 2.6.17-1.2187_FC5 I can confirm that your patch does work.

Note You need to log in before you can comment on or make changes to this bug.