linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Eric Paris <eparis@redhat.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	viro@zeniv.linux.org.uk, hch@infradead.org
Subject: Re: [PATCH] VFS: document what MAY_ACCESS means
Date: Mon, 21 Sep 2009 19:53:36 +0100	[thread overview]
Message-ID: <20090921185336.GA5633@shareable.org> (raw)
In-Reply-To: <1253536193.17222.21.camel@heimdal.trondhjem.org>

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

  reply	other threads:[~2009-09-21 18:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-21  1:29 [PATCH] VFS: document what MAY_ACCESS means Eric Paris
2009-09-21  1:52 ` Nicholas Miell
2009-09-21  8:10 ` Jamie Lokier
2009-09-21 12:29   ` Trond Myklebust
2009-09-21 18:53     ` Jamie Lokier [this message]
2009-09-21 20:18       ` Trond Myklebust
2009-09-21 21:39         ` fchdir, EACCESS and when to check (was: [PATCH] VFS: document what MAY_ACCESS means) Jamie Lokier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090921185336.GA5633@shareable.org \
    --to=jamie@shareable.org \
    --cc=eparis@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).