On Mon, 2009-09-21 at 19:53 +0100, Jamie Lokier wrote:
> Trond Myklebust wrote:
> > On Mon, 2009-09-21 at 09:10 +0100, Jamie Lokier wrote
> > > (Btw, side issue: I was very surprised to find fchdir() to an open
> > > directory can fail on NFS due to change of permissions, so the pattern
> > > dir = open("."); chdir("foo"); fchdir(dir) can fail to restore the
> > > current directory).
> >
> > Welcome to the world of stateless server-enforced security. Unlike the
> > POSIX model, a NFS server doesn't have the ability to track what
> > permissions have already been checked using a file descriptor. It
> > therefore needs to check permissions on each RPC operation you perform
> > using the credential you present then and there.
>
> No, no, it's not that.
>
> It's allowed to have the current directory be a directory you can't
> access any more. You find out you've lost permission, as you say,
> later when you _do_ something with the directory. In other words when
> you do a lookup or readdir from the directory.
>
> Putting it another way, this will _never_ error due to another process
> messing with the permissions of the original directory after subdir is
> opened:
>
> dir=open(".");
> dir2=open("/elsewhere");
> fstatat(dir2, "something_elsewhere");
>
> But this can fail, leaving you in a different directory:
>
> dir=open(".");
> dir2=open("/elsewhere");
> fchdir(dir2);
> stat("something_elsewhere");
> fchdir(dir);
>
> I find that surprising. Imho, both codes are intended to have the
> same behaviour.
>
> Is there something in POSIX which says fchdir() must verify you still
> have execute permission in the directory you are switching to at the
> time you call fchdir()?
>
> I suspect having fchdir() fail in this admittedly obscure case is more
> likely to cause problems than the RPC permission check, due to
> surprise and no obvious error recovery strategy in an application
> where fchdir is used in some subroutine to temporarily switch
> directory and then return to the caller, which doesn't expect the
> current directory might be changed by the call. I suspect when that
> happens, most applications will either terminate abruptly or behave
> wrongly later. It's just a guess though....
Oh, I see what you're getting at.
So, looking at the code for fchdir(), it would appear that the
permission check there is being made by the VFS, not NFS. I suspect that
is because it is mandated by POSIX.
Indeed, looking at the spec for fchdir(), it would appear that you _do_
need valid permissions. See
http://www.opengroup.org/onlinepubs/009695399/functions/fchdir.html
which states that the function returns EACCES if the process doesn't
have search permissions.
Cheers
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
