Petr Baudis <[email protected]> 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?
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
