Message-Id: <1157429030.3915.8.camel@raven.themaw.net>
Date:	Tue, 05 Sep 2006 12:03:50 +0800
From:	Ian Kent <raven@...maw.net>
To:	Trond Myklebust <trond.myklebust@....uio.no>
Cc:	David Howells <dhowells@...hat.com>, Andrew Morton <akpm@...l.org>,
	torvalds@...l.org, steved@...hat.com,
	linux-fsdevel@...r.kernel.org, linux-cachefs@...hat.com,
	nfsv4@...ux-nfs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] Permit filesystem local caching and NFS superblock
	sharing [try #13]

On Mon, 2006-09-04 at 23:50 -0400, Trond Myklebust wrote:
> On Tue, 2006-09-05 at 10:55 +0800, Ian Kent wrote:
> > On Mon, 2006-09-04 at 21:57 -0400, Trond Myklebust wrote:
> > > On Mon, 2006-09-04 at 21:24 +0800, Ian Kent wrote:
> > > 
> > > > > [pid  3838] mkdir("/net", 0555)         = -1 EEXIST (File exists)
> > > > > [pid  3838] stat64("/net", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> > > > > [pid  3838] mkdir("/net/trash", 0555)   = -1 EEXIST (File exists)
> > > > > [pid  3838] stat64("/net/trash", {st_mode=S_IFDIR|0555, st_size=1024, ...}) = 0
> > > > > [pid  3838] mkdir("/net/trash/mnt", 0555) = -1 EACCES (Permission denied)
> > > > 
> > > > This is the point I'm trying to make.
> > > > I'm able to reproduce this with exports that don't have "nohide".
> > > > The mkdir used to return EEXIST, possibly before getting to the EACCES
> > > > test. It appears to be a change in semantic behavior and I can't see
> > > > where it is coming from. autofs expects an EEXIST but not an EACCES and
> > > > so doesn't perform the mount. I could ignore the EACCES but that would
> > > > be cheating.
> > > 
> > > Why the hell is it doing a mkdir in the first place? ...and why the hell
> > > is it not able to cope with EACCES? The latter is hardly an unlikely
> > > reply: it means that the automounter should not be doing this in the
> > > first place, 'cos it doesn't have the privileges. That is not the same
> > > as saying that it doesn't have the privileges to do a lookup.
> > 
> > Why the hell shouldn't it be able to do an mkdir!
> 
> Firstly, if the call to mkdir actually _was_ successful, it would be
> creating a new directory on the NFS server, and it would be doing so
> with the automounter's privileges instead of the user's privileges. Why
> would I want it to do that?
> 
> Secondly, and more pertinently to this case, you have no guarantee that
> the automounter has _any_ privileges on the server at all other than
> what is required to mount a filesystem. selinux is enforcing that on the
> client side here, but the server could just as well be set up to do the
> same (in fact, you could set up selinux to do the exact same thing on
> the server).
> 
> IOW, the automounter should just be calling stat('/net/trash/mnt'). It
> shouldn't be trying to create directories on the server at all.

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.

> 
> > 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.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists