Messages in this thread | | | Subject | Re: [RESEND][PATCH] Let even non-dumpable tasks access /proc/self/fd | From | Jeff Layton <> | Date | Wed, 05 Jul 2006 12:07:26 -0400 |
| |
On Tue, 2006-06-20 at 00:24 -0600, Eric W. Biederman wrote: > Andrew Morton <akpm@osdl.org> writes: > > > On Fri, 16 Jun 2006 14:41:57 +0200 > > Petr Baudis <pasky@suse.cz> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |