[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AE84017.7040101@hp.com>
Date: Wed, 28 Oct 2009 08:59:03 -0400
From: jim owens <jowens@...com>
To: "Rafael J. Wysocki" <rjw@...k.pl>
CC: Eric Paris <eparis@...isplace.org>,
Robert Hancock <hancockrwd@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kernel Testers List <kernel-testers@...r.kernel.org>
Subject: Re: [Bug #14474] restorecond going crazy on 2.6.31.4 - inotify regression?
Rafael J. Wysocki wrote:
> On Tuesday 27 October 2009, Eric Paris wrote:
>> It's a restorecond bug. restorecon acted as if watch descriptors
>> could never be reused. They weren't on old kernels and it's possible
>> they are reused now. Restorecon was fixed.
>>
>> http://marc.info/?l=selinux&m=125380417916233&w=2
>>
>> a change in the kernel caused a buggy userspace program to break. I
>> know how to put the kernel back the way it was, but I don't know if we
>> call this a regression, you guys tell me.
>
> Yes, we do, AFAICS. The policy is not to break user space, even if it happens
> to work by accident.
But if we make a rule of "never break even bad user programs" then
we also should never plug security holes because that breaks a
user program expecting that attack vector :)
Silly example, but the point is we need to decide if the
user program would have done something wrong eventually
anyway (as in if the system was up long enough, they would
have hit a duplicate id and failed with the old kernel) so
the kernel change just makes it easy to hit the user code bug.
jim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists