All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: oleg@redhat.com, viro@zeniv.linux.org.uk,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] supress uid comparison test if core output files are pipes
Date: Wed, 24 Feb 2010 18:13:32 -0800	[thread overview]
Message-ID: <20100224181332.5cdc2454.akpm@linux-foundation.org> (raw)
In-Reply-To: <20100225013210.GA10527@localhost.localdomain>

On Wed, 24 Feb 2010 20:32:10 -0500 Neil Horman <nhorman@tuxdriver.com> wrote:

> > > diff --git a/fs/exec.c b/fs/exec.c
> > > index 6303d18..6af2214 100644
> > > --- a/fs/exec.c
> > > +++ b/fs/exec.c
> > > @@ -1987,8 +1987,9 @@ void do_coredump(long signr, int exit_code, struct pt_regs *regs)
> > >  	/*
> > >  	 * Dont allow local users get cute and trick others to coredump
> > >  	 * into their pre-created files:
> > > +	 * Note, this is not relevant for pipes
> > >  	 */
> > > -	if (inode->i_uid != current_fsuid())
> > > +	if (!ispipe && (inode->i_uid != current_fsuid()))
> > >  		goto close_fail;
> > >  	if (!cprm.file->f_op)
> > >  		goto close_fail;
> > 
> > hm, this actually appears to fix a regression, added by:
> > 
> In a sense yes.  Previously though, Ingos check was both useless for pipes
> (since you can't have a user create a pipe that will map to what the coredump
> path creates anyway, making this check useless), but it worked anyway, since the
> crashing process created the pipe, so the uid check always matched.  With the
> refactoring andi and I did, thats no longer true, so the check could fail.  This
> patch just fixes it up by recongnizing that the check isn't needed at all for
> pipes

Which refactoring?  Please identify precisely the patch which this patch fixes up?

  reply	other threads:[~2010-02-25  2:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-22 20:44 [PATCH] supress uid comparison test if core output files are pipes Neil Horman
2010-02-24 11:09 ` Oleg Nesterov
2010-02-24 11:50   ` Neil Horman
2010-02-24 21:50 ` Andrew Morton
2010-02-25  1:32   ` Neil Horman
2010-02-25  2:13     ` Andrew Morton [this message]
2010-02-25 11:52       ` Neil Horman

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=20100224181332.5cdc2454.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nhorman@tuxdriver.com \
    --cc=oleg@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.