[lkml]   [2008]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Bug #11500] /proc/net bug related to selinux
On Wed, 17 Sep 2008 17:24:36 -0400
Paul Moore <> wrote:

> On Wednesday 17 September 2008 3:50:53 pm Andrew Morton wrote:
> > On Mon, 15 Sep 2008 09:05:26 -0400
> > Stephen Smalley <> wrote:
> > > However, the most likely explanation is simply that when /proc/net
> > > was changed from being a directory to being a symlink to
> > > /proc/self/net, that introduced an additional permission check on
> > > accesses of /proc/net/<whatever>, namely the read check on the
> > > symlink itself. And since that check wasn't happening on /proc/net
> > > accesses with older kernels, older policies didn't allow it.
> > >
> > > As to why others haven't reported it, I expect that they have
> > > updated their policies to newer ones that allow the necessary
> > > access. The fact that legacy distros wouldn't have such updated
> > > policies isn't surprising - they don't push updates to those
> > > distros for new kernels. FC5 and FC6 are both EOL'd, right?
> > >
> > > In any event, we didn't change anything in SELinux - the change was
> > > elsewhere (in the proc/net implementation). Don't blame the
> > > messenger please.
> >
> > Vanilla FC5 broke and vanilla FC6 broke. Did vanilla FC7, 8 or 9
> > break?
> >
> > shows
> > 11,000-odd people running FC5 and FC6. It would be incautious to
> > assume that all those people have updated their selinux rules.
> >
> > And _requiring_ people to update their selinux rules to fix a
> > kernel-caused regression is a pretty big deal for some people, I
> > expect.
> Just so I'm clear on the context of the problem, it sounds like if a FC5
> (I'm limiting myself to FC5 for the moment) user upgraded to a recent
> (2.6.25+) kernel (non-distro supplied in the case of FC5) then they
> will run into problems unless they also upgrade their SELinux policy,
> yes?

That only true if the 2.6.25+ kernel is
backward-incompatible with the distro kernel.

> If that is the case I'm not sure it is really that big of a deal. Maybe
> I'm in the minority here, but in my mind once you step away from the
> distro supplied kernel (also applies to other packages, although those
> are arguably less critical) you should also bear the responsibility to
> make sure you upgrade/tweak/install whatever other bits need to be
> fixed.

Nope. Releasing a non-backward-compatible kernel is a big

We'll do it sometimes, with long notice, much care and much deliberation.

We did it this time by sheer accident. That's known in the trade as a

> > Then again, given that this regression has been out there since
> > 2.6.25, I guess not too many people are hurting from it. But we
> > suck.
> We suck? Maybe, but some explanation about why we suck in this
> particular case would be helpful as far as I'm concerned. I don't
> really care about identifying the guilty suckees, I'm more interested
> in finding out what happened to cause us to suck because of this.

Because we unintentionally and unknowingly released a kernel which is
not compatible with previous kernels without notifying any of our users
and without any consideration or planning.

Yes, often the consequences of the screwup are fairly small, but it's a
screwup nonetheless.

We don't even know the extent of the damage yet. Which distros were
affected? With which versions of which userspace packages?

 \ /
  Last update: 2008-09-17 23:53    [W:0.138 / U:2.072 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site