[lkml]   [2006]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Dumpable tasks and ownership of /proc/*/fd
    Petr Baudis <> writes:

    > Hello,
    > I would like to ask why is /proc/*/fd owned by root when the task is
    > not dumpable - what security concern does it address? It would seem more
    > reasonable to me if the /proc/*/fd owner would be simply always the real
    > uid of the process.
    > The issue is that now all tasks calling setuid() from root to non-root
    > during their lifetime will not be able to access their /proc/self/fd.
    > This is troublesome because the fstatat() and other *at() routines are
    > emulated by accessing /proc/self/fd/*/path and that will break with
    > setuid()ing programs, leading to various weird consequences (e.g. with
    > the latest glibc, nftw() does not work with setuid()ing programs and
    > furthermore causes the LSB testsuite to fail because of this, etc.).

    Looking at it the current check is indeed incorrect.
    Primarily because it is a check on open and not a check
    on access. We can open the directory anytime so if
    this is a serious permission we need to check on access.

    Further when it is ourselves we always have access to that
    information directly, and /proc is just a convenience. So
    we should not be denying ourselves.

    Other processes we do need to deny if we aren't dumpable because
    they don't have another way to get that information.

    Speaking of things why does the *at() emulation need to touch
    /proc/self/fd/*? I may be completely dense but if the practical
    justification for allowing access to /proc/self/fd/ is that we
    already have access then we shouldn't need /proc/self/fd.

    I suspect this a matter of convenience where you are prepending
    /proc/self/fd/xxx/ to the path before you open it instead of calling
    fchdir openat() and the doing fchdir back. Have I properly guessed
    how the *at() emulation works?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-04-10 07:46    [W:0.020 / U:163.064 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site