linux-kernel - Re: [PATCH] VFS: document what MAY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1253564285.17222.120.camel@heimdal.trondhjem.org>
Date:	Mon, 21 Sep 2009 16:18:05 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk,
	hch@...radead.org
Subject: Re: [PATCH] VFS: document what MAY_ACCESS means

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