lkml.org 
[lkml]   [2009]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectfchdir, EACCESS and when to check (was: [PATCH] VFS: document what MAY_ACCESS means)
Trond Myklebust wrote:
> > 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.

Sadly I think you're right. The check is performed locally, too.
It's not an NFS quirk (unlike, say, read permissions), and local
concurrency can trip it up.

Well well well.

http://www.mail-archive.com/bug-gnulib@gnu.org/msg12513.html

"using only fchdir does have the advantage that we know that
restoring the current directory can't fail. (It can fail IIRC on
SunOS, but I think we don't support the affected versions any
more)."

That doesn't look convincing any more.

[Have added James Youngman who wrote that, to Cc]

Let's look around:

http://www.opengroup.org/onlinepubs/9699919799/functions/openat.html

"the file to be opened is determined relative to the directory
associated with the file descriptor fd instead of the current
working directory. If the file descriptor was opened without
O_SEARCH, the function shall check whether directory searches are
permitted using the current permissions of the directory
underlying the file descriptor. If the file descriptor was opened
with O_SEARCH, the function shall not perform the check."

Also,
http://www.opengroup.org/austin/docs/austin_383.txt

That's not about fchdir(), but it's a general property of directories
opened with O_SEARCH when used with *at() functions.

fchdir() doesn't apply the "shall not perform the check" rule. It's
only used for *at() lookups. Given the existence of any rule which
allows search permission to be checked at open() time and not checked
later, it looks like it might be quite useful for fchdir() to have the
same property, so you'd know you can always return to a directory if you
successfully opened it before.

I've added Ulrich Drepper to the Cc list in case he cares to say
something about fchdir(), since he seems to have introduced O_SEARCH
to SUS.

Ulrich, do you think fchdir should fail even if you successfully
opened a directory with O_SEARCH (if that is eventually implemented in
Linux ;-), when the permissions have been changed after the descriptor
is opened, even though all the *at() functions can successfully search
using the descriptor?

-- Jamie


\
 
 \ /
  Last update: 2009-09-21 23:43    [W:0.048 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site