This bug was fixed in the package apparmor - 3.0.4-2ubuntu2.2
---
apparmor (3.0.4-2ubuntu2.2) jammy; urgency=medium
* Add mqueue patches. LP: #1993353
- u/mqueue1-parser-add-parser-support-for-message-queue-mediatio.patch:
add parser support for mqueue mediation
-
Tests for jammy worked as expected. The systemd autopkgtest on s390x
passed after the test was retriggered.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1994146
Title:
** Tags removed: verification-needed verification-needed-jammy
** Tags added: verification-done verification-done-jammy
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
** Changed in: apparmor (Ubuntu Focal)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1994146
Title:
[SRU] apparmor - Focal,
@sil2100, there is some additional testing. qa-regression-testing, pulls
in the apparmor regression tests. And they contain tests for
capabilities and mqueue behavior. These have not shown any regressions.
And have been tested on multiple machines.
These patches have also gone through the build
** Tags removed: verification-needed-focal
** Tags added: verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1994146
Title:
[SRU] apparmor - Focal,
I accepted this, but would prefer to keep these patches around for some
longer testing. Would it be possible to maybe get a call-for-testing out
or similar? Also, we need to make sure that the existing behaviour is
preserved, so I'd request for https://code.launchpad.net/~georgiag/qa-
Hello Georgia, or anyone else affected,
Accepted apparmor into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu5.2 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
Hi Łukasz,
Thanks for the update. What's the status of the focal SRU? That's the
time-critical one for our customer.
Cheers,
Isaac
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
Hello Georgia, or anyone else affected,
Accepted apparmor into jammy-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/apparmor/3.0.4-2ubuntu2.2 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
Excellent! Okay, let me have one more look and then possibly get this
into -proposed.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1994146
Title:
[SRU] apparmor -
Łukasz, the commits that are "missing" from the upstream merge request
had already been merged.
They are:
mqueue8-libapparmor-add-support-for-requested-and-denied-on-.patch
mqueue9-libapparmor-add-support-for-class-in-logparsing.patch
Corresponding commits upstream:
Okay, looking at all the comments and discussions, I personally feel
that we're getting there. I just have a final less-exciting question:
As mvo mentioned, it looks like the changes got merged upstream. But
when I look at the upstream merge, there seems to be less commits in
there than patches
Fwiw, the code has landed in the upstream git repository in
https://gitlab.com/apparmor/apparmor/-/merge_requests/858
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1994146
Chris, I added the missing SRU information on the bugs that were
missing.
> The packaging itself looks sane, but my understanding is that this adds
> new classes of apparmor denials, and *particularly* it appears that this
> might cause existing apparmor profiles to deny application behaviour
>
** Merge proposal linked:
https://code.launchpad.net/~georgiag/qa-regression-testing/+git/qa-regression-testing/+merge/433546
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
Is this also contemplating
https://bugs.launchpad.net/ubuntu/jammy/+source/apparmor/+bug/1979879
for jammy? I'll try to take a look
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
So, I'm not Steve, but as this is a priority and I know Steve is off
this week I've taken a look at this to hopefully resolve some review
questions before he's back.
A number of the bugs referenced in this upload don't have the relevant
SRU information attached, which would be helpful.
The
Hi Ijlal,
That's correct - the SRU to focal (and thus core 20) is the important
one for the customer.
Cheers,
Isaac
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1994146
Hi Issac, Steve, Georgia,
I think that our customer mainly depend of the Focal patches to be
SRU'ed. May be Steve can prioritize them and help us get those reviewed
first.
Thank you !
Ijlal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
Hi Steve,
Just wanted to mention that this is a very time-critical feature
requirement for one of our customers on Core 20, so we would really
appreciate this if you could please treat this as very high priority.
Please feel free to reach out to me on MM if you have any questions.
Cheers,
Isaac
Hi Steve Langasek, thanks for taking a look at the SRU.
> Is that not what this means, or is mqueue access actually denied by
> default and this refers only to how an unqualified 'mqueue' rule is
> interpreted?
Correct, this only refers to how an unqualified 'mqueue' rule is
interpreted.
> In
> The message queue rules support could cause issues for AppArmor
> policies that were developed before there was support for mqueues,
Please explain in more detail why this is a risk. reading the
'mqueue1-' patch, the documentation reads to me as the default being
full access allowed:
These have now been uploaded to -proposed and are sitting in UNAPPROVED:
https://launchpad.net/ubuntu/jammy/+queue?queue_state=1_text=apparmor
https://launchpad.net/ubuntu/focal/+queue?queue_state=1_text=apparmor
** Changed in: apparmor (Ubuntu Focal)
Status: Confirmed => In Progress
**
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apparmor (Ubuntu Focal)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apparmor (Ubuntu Jammy)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apparmor (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
27 matches
Mail list logo
