Message-ID: <c0cbecb6-63c8-17a6-9c5e-59de27d3c5e9@leemhuis.info>
Date:   Tue, 24 Oct 2017 08:39:28 +0200
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     John Johansen <john.johansen@...onical.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        James Bottomley <James.Bottomley@...senPartnership.com>,
        Seth Arnold <seth.arnold@...onical.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: regression in 4.14-rc2 caused by apparmor: add base infastructure
 for socket mediation

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

Powered by blists - more mailing lists