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
next prev parent 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