From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751998AbdJXL5i (ORCPT ); Tue, 24 Oct 2017 07:57:38 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:42840 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751865AbdJXL5h (ORCPT ); Tue, 24 Oct 2017 07:57:37 -0400 Subject: Re: regression in 4.14-rc2 caused by apparmor: add base infastructure for socket mediation To: James Bottomley , Thorsten Leemhuis , Vlastimil Babka , Seth Arnold Cc: linux-kernel References: <1507003338.3174.4.camel@HansenPartnership.com> <1507007707.3082.16.camel@HansenPartnership.com> <5d57381f-e915-1b8f-7838-eba46ab89f34@suse.cz> <1508842981.3187.5.camel@HansenPartnership.com> From: John Johansen Organization: Canonical Message-ID: <722a6eda-e834-30f8-bf57-ef6c596816f6@canonical.com> Date: Tue, 24 Oct 2017 04:57:32 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1508842981.3187.5.camel@HansenPartnership.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/24/2017 04:03 AM, James Bottomley wrote: > On Tue, 2017-10-24 at 08:39 +0200, Thorsten Leemhuis wrote: >> Lo, your friendly regression tracker here! >> >> On 03.10.2017 09:17, John Johansen wrote: >>> >>> On 10/02/2017 11:48 PM, Vlastimil Babka wrote: >>>> >>>> On 10/03/2017 07:15 AM, James Bottomley wrote: >>>>> >>>>> On Mon, 2017-10-02 at 21:11 -0700, John Johansen wrote: >>>>>> >>>>>> On 10/02/2017 09:02 PM, James Bottomley wrote: >>>>>>> >>>>>>> >>>>>>> The specific problem is that dnsmasq refuses to start on >>>>>>> openSUSE Leap 42.2. The specific cause is that and attempt >>>>>>> to open a PF_LOCAL socket gets EACCES. This means that >>>>>>> networking doesn't function on a system with a 4.14-rc2 >>>>>>> system. Reverting commit >>>>>>> 651e28c5537abb39076d3949fb7618536f1d242e >>>>>>> (apparmor: add base infastructure for socket mediation) >>>>>>> causes the system to function again. >>>>>> This is not a kernel regression, >>>>> Regression means something that worked in a previous version of >>>>> the kernel which is broken now. This problem falls within that >>>>> definition. >>>> Hm, but if this was because opensuse kernel and apparmor rules >>>> relied on an out-of-tree patch, then it's not an upstream >>>> regression? >>> While its true that previous opensuse kernels were relying on an >>> out of tree patch for doing mediation in this area, the real issue >>> is the configuration of the userspace on the system is setup to >>> enforce new policy features advertised by the kernel. Regardless of >>> whether policy has been updated to deal with it. >> >> Did anything came out of this discussion? > > Not really, no. I've got the patch reverted locally, so it's not > causing *me* problems anymore. > actually a lot of work and testing has been done. A regression was found, the fix is in testing and it should land soon, but its not the regression you are having issues with. >> I checked LKML and recent commits, but missed if anything happened. >> But it seems this problem annoys quite a few of people on various >> distros. It turned out one of the the regressions in my last >> regression report seemed to be due to the changes in apparmor. See: >> >> https://bugzilla.kernel.org/show_bug.cgi?id=197137#7 >> >> That commit links to two bugs filed for Debian and Ubuntu: >> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1724450 >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877581 >> >> The stuff even made the news: >> https://www.phoronix.com/scan.php?page=news_item&px=AppArmor-Linux-4. >> 14 >> >> It's obviously Linus to decide in the end, but from my understanding >> of the whole "no regressions" rule this looks quite a lot like a >> regression to me. > > It's certainly a lack of co-ordination between all the apparmour using > upstreams, yes. I think of it as a regression because I have no way > other than reverting the patch of getting my system running again. > its not a lack of coordination, regardless of coordination this would have happened for people front running the suse distro kernel due to how the apparmor userspace is configured. Could it have been handled better for kernel devs? Certainly, but the issue you are encountering is a userspace configuration issue. Distros get to choose how apparmor is configured, and what certain defaults are. The suse default configuration is to not pin the features abi (there are pros and cons depending on what you want), which essentially means if you are front running the distro kernel and policy with an upstream kernel you are a policy dev, and you are going to be hit with stuff like this. You have a couple userspace options available to you and a couple kernel options without having to revert the patch. - You can update your policy. - You can pin the feature set abi to that of the distro kernel, and what your policy was developed for. - You can disable apparmor in grub - You can disable apparmor in the kernel config I have been discussing pinning the feature abi with distros maintainers (the ability has been around for years) and the Debian maintainer has been planning, for a while now, to use it by default for stable releases. However a similar decision has not been made for other distros yet. Long term we are working on a more flexible solution, that won't require having to choose to pin the features abi but it is not available yet. > I'd also argue that treating this as a regression might possibly > encourage better co-ordination in future. > > James >