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? 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. Ciao, Thorsten > > Distros should be pinning the feature set supported because as you > note below, policy will not get updated for unsupported kernels and you > will end up in an unsupported state where regressions like this can > happen. > > There are reasons why distros don't, largely because certain packages > would like to take advanatage of new features, or only want to support > a single policy version across multiple releases and are relying on > the userspace tools to properly compile the policy to different > kernels. > > The current pinning support doesn't allow for mixing policy versions > which can make supporting updated packages difficult atm, but there is > work (that hasn't landed yet) to allow for policy of different version > by putting the requirements within the individual profiles and will > completely avoid the problems encountered here. > > >>>> it is because opensuse dnsmasque is starting with policy that >>>> doesn't allow access to PF_LOCAL socket >>> >>> Because there was no co-ordination between their version of the patch >>> and yours. If you're sending in patches that you know might break >>> systems because they need a co-ordinated rollout of something in >>> userspace then it would be nice if you could co-ordinate it ... >>> >>> Doing it in the merge window and not in -rc2 would also be helpful >>> because I have more expectation of a userspace mismatch from stuff in >>> the merge window. >> >> Agree, but with rc2 there's still plenty of time, and running rcX means >> some issues can be expected... >> >>>> Christian Boltz the opensuse apparmor maintainer has been working >>>> on a policy update for opensuse see bug >>>> >>>> https://bugzilla.opensuse.org/show_bug.cgi?id=1061195 >>> >>> Well, that looks really encouraging: The line about "To give you an >>> impression what "lots of" means - I had to adjust 40 profiles on my >>> laptop". The upshot being apart from a bandaid, openSUSE still has no >>> co-ordinated fix for this. >> >> Note that the openSUSE Leap 42.2 kernel is 4.4, so by running 4.14 means >> you are unsupported from the distro POV and you can't expect that the >> 42.2 apparmor profiles will ever be updated. I reported the bug above >> for the Tumbleweed rolling distro, which gets new kernels after the >> final version is released and passes QA. rcX kernels are packaged for >> testing, but you have to add the repo explicitly. So there's still >> enough time to co-ordinate fix of profiles and final 4.14 even for >> Tumbleweed. >> >>> James
