Re: [RESEND][PATCH] Let even non-dumpable tasks access/proc/self/fd

From: Jeff Layton
Date: Wed Jul 05 2006 - 12:06:25 EST


On Tue, 2006-06-20 at 00:24 -0600, Eric W. Biederman wrote:
> Andrew Morton <akpm@xxxxxxxx> writes:
>
> > On Fri, 16 Jun 2006 14:41:57 +0200
> > Petr Baudis <pasky@xxxxxxx> wrote:
> >
> >> 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 on ppc and furthermore
> >> causes the LSB testsuite to fail because of this).
> >
> > Odd. Did something actually change in glibc to make this start happening?
> >
> >> This kernel patch fixes the problem by letting the process access its
> >> own /proc/self/fd - as far as I can see, this should be reasonably safe
> >> since for the process, this does not reveal "anything new". Feel free to
> >> comment on this.
> >>
> >
> > Eric, Chris - any thought on this one?
>
> This can't fix the glibc emulation problem. As the kernel
> this patch would apply to doesn't need emulation.
>
> The basic goal of allowing the current process to access it's
> own proc directories is reasonable.
>
> I don't like the implementation. It is not obvious that this case
> applies just to the current process.
>
> I admit that any permission checking in /proc that happens at
> open time instead of at access time is buggy but that is
> the best we have right now.
>
> Anything more requires a very close review.
>
>
> Eric

This might be a stupid question, but can someone explain to me why all
of this whole thing is keyed off of the dumpable flag? With the current
scheme setting suid_dumpable to true works around this problem, but that
doesn't seem like it's an intended behavior.

Also, I recently had someone report a problem where a program that
dropped its privileges was not able access /proc/self/maps. So making so
that we can access /proc/self/fd might not be sufficient.

Perhaps we should consider making this use a blacklist instead of a
whitelist approach? That is to make pid_revalidate to change the
ownership of anything under /proc/self to the euid irrespective of the
dumpable flag, except for things that we know need to retain the
previous ownership?

-- Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/