public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Malicki <jmalicki@metacarta.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Kenneth Baker <bakerkj@metacarta.com>,
	Michael Itz <mitz@metacarta.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: BUG: setuid sometimes doesn't.
Date: Tue, 3 Mar 2009 20:28:46 -0500 (EST)	[thread overview]
Message-ID: <5025982.10132161236130126636.JavaMail.root@ouachita> (raw)
In-Reply-To: <Pine.LNX.4.64.0903031037590.13485@blonde.anvils>

----- "Hugh Dickins" <hugh@veritas.com> wrote:

> > 
> > Thanks for the attention!  This didn't seem to fix our problem
> > (surprisingly) since it does seem to fit with the finer details:
> 
> I'm sorry if I've wasted your time, but I am not surprised now.

Oh, not at all!  We're glad to help you out since we have a platform
that can reproduce, it's not that much work at this point to test a
patch (given we've already got a minimal reproduction case etc.)

> I went back to look closer, and the fs->count on /proc/*/{cwd,root}
> is merely the most obvious case: files->count is equally vulnerable
> to lookups on /proc/*/fd/*, via get_files_struct() calls (but the
> third LSM_UNSAFE_SHARE, sighand->count, appears to be of no
> interest to /proc, so safe from this point of view).

Good catch, I missed that (I had trouble tracking down everything
involved in /proc - I was looking for that case but overlooked it).

> So I think my patch was seriously incomplete.  However, the
> files->count
> case looks a lot harder to fix than the fs->count one.  Having
> started
> on this issue, I'd better do my best to come up with a fix to the
> files
> count side of it too, but must give it a little thought and time, and
> will need to CC some good people even if I do manage a patch - it's
> all too easy to fix this but introduce other more serious security
> or data lifetime errors.
>
> It would be nice to offer a preliminary patch which at least confirms
> that it is this /proc access which is causing the problem; but I
> didn't
> see how to do that without going all out for a fix.  Perhaps I'll
> have
> to compromise on a racy patch just to confirm the issue, we'll see.

I suppose we can test by ignoring the files->count for LSM_UNSAFE_SHARE
(it doesn't prove it's /proc, but at least narrows things down somewhat).
 
> > 
> > 1) The software load we were running it on does a health check every
> few minutes
> >    which, among other things, executes several lsof and ss
> (sockstat) processes.
> 
> lsof, yes, that fits exactly (perhaps ss equally but I don't know).
> 
> I'm afraid your health check is endangering the health of your
> system!
> But I do think the kernel's unreliable setuid is unacceptable
> behaviour.

The irony!

 
> > 
> > I could not reproduce the problem without our system-health-monitor
> process,
> > or on several other machines at home (Ubuntu 8.04 and Ubuntu 8.10
> with updated
> > kernels, running multicore).  So I am very suspicious of that race,
> although your
> > patch didn't seem to fix it.... (?!?!)
> 
> I didn't manage to reproduce it here myself either,
> though perhaps I should have tried on more machines.

I suspect it is something subtle about our workload that we haven't
entirely isolated (merely running lsof in a loop oddly doesn't seem
sufficient...)

> I'll get back to you... but not immediately.
> 
> Hugh

Given that this bug occurs exceedingly rarely "in the wild" outside of
our minimal test case, a delay isn't a concern.

Thanks!
Joe Malicki

  reply	other threads:[~2009-03-04  1:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <15171620.10049841236049960269.JavaMail.root@ouachita>
2009-03-03  3:16 ` BUG: setuid sometimes doesn't Joe Malicki
2009-03-03 11:16   ` Hugh Dickins
2009-03-04  1:28     ` Joe Malicki [this message]
     [not found] <10783026.9717361235603356623.JavaMail.root@ouachita>
2009-02-25 23:11 ` Joe Malicki
2009-02-26  0:28   ` Andrew Morton
2009-02-26 13:17     ` Joe Malicki
2009-02-26 12:06   ` Joe Malicki
2009-02-26 16:06     ` Hugh Dickins

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=5025982.10132161236130126636.JavaMail.root@ouachita \
    --to=jmalicki@metacarta.com \
    --cc=akpm@linux-foundation.org \
    --cc=bakerkj@metacarta.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mitz@metacarta.com \
    /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