mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@osdl.org>
Cc: Petr Baudis <pasky@suse.cz>,
	linux-kernel@vger.kernel.org, Chris Wright <chrisw@sous-sol.org>,
	Ulrich Drepper <drepper@redhat.com>
Subject: Re: [RESEND][PATCH] Let even non-dumpable tasks access /proc/self/fd
Date: Tue, 20 Jun 2006 00:24:30 -0600	[thread overview]
Message-ID: <m1veqwfiox.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060619204851.84467440.akpm@osdl.org> (Andrew Morton's message of "Mon, 19 Jun 2006 20:48:51 -0700")

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

  reply	other threads:[~2006-06-20  6:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-16 12:41 Petr Baudis
2006-06-20  3:48 ` Andrew Morton
2006-06-20  6:24   ` Eric W. Biederman [this message]
2006-07-05 16:07     ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1veqwfiox.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@osdl.org \
    --cc=chrisw@sous-sol.org \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pasky@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome