Re: [PATCH 0/7] Permit filesystem local caching and NFS superblock sharing [try #13]

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Tue, 2006-09-05 at 12:03 +0800, Ian Kent wrote:
> Sure but this is an old version of autofs which is in use so changing
> the expected behavior of a system call is not acceptable and I expect
> other applications may well have a problem with this also.

Applications that rely on mkdir() to never return EACCES are broken.
Particularly so in an selinux system (as was the case here).

Note that an ordinary application will not see this: if I do

Machine 1				Machine 2
---------				---------
mkdir foo
					mkdir foo/bar
					chmod 555 foo/bar foo
mkdir foo/bar
mkdir: cannot create directory 
`foo/bar': File exists

i.e. as expected. So this really only affects applications that are not
supposed to be calling mkdir() in the first place.

> > > It is coping with the EACCESS return by not mounting the filesystem
> > > which is the correct response in this case.
> > 
> > No it isn't. The directory exists. It can be looked up. There is no
> > reason why you can't mount something on top of it.
> > 
> > Being permitted to do mkdir() or not has nothing to do with anything.
> 
> Agreed.
> 
> The fact that it's a mkdir is irrelevant given that nfs_lookup is
> returning an EACCESS instead of EEXIST this will likely affect other
> system calls such as "stat". I'll check this.

In both cases, the call to vfs_mkdir() is returning the EACCES. Not
nfs_lookup. The reason why we are no longer returning EEXIST is because
the intents have changed due to the patch

http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a634904a7de0d3a0bc606f608007a34e8c05bfee;hp=ddeff520f02b92128132c282c350fa72afffb84a

I suspect that reverting that patch would 'fix' the autofs bug.