lkml.org 
[lkml]   [2006]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 0/7] Permit filesystem local caching and NFS superblock sharing [try #13]
From
Date
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-09-05 06:07    [W:0.090 / U:5.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site