[lkml]   [2009]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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
    > 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.

    "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

    That doesn't look convincing any more.

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

    Let's look around:

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


    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.083 / U:84.128 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site