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