@{pid} variable broken on systems with pid_max more than 6 digits

Bug #1717714 reported by Andre Tomt on 2017-09-16
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AppArmor
Undecided
Unassigned
2.11
Undecided
Unassigned
apparmor (Debian)
Fix Released
Unknown
apparmor (Ubuntu)
Medium
Seyeong Kim
Trusty
Medium
Eric Desrochers
Xenial
Medium
Seyeong Kim
Artful
Medium
Seyeong Kim
Bionic
Medium
Seyeong Kim

Bug Description

[Impact]

If PID is larger than 6 digits apparmor denies process which only affect 64-bit systems[1] where the PID_MAX_LIMIT can be generated up to 7 digits at the maximum.

This fix is committed, but not released. so all supporting version are affected.

[1] - man 5 proc

--------------------------------------------------------------------------
/proc/sys/kernel/pid_max (since Linux 2.5.34)
This file specifies the value at which PIDs wrap around (i.e., the value in this file is one greater than the maximum PID). PIDs greater than this value are not allocated; thus, the value in this file also acts as a system-wide limit on the total number of processes and threads. The default value for this file, 32768, results in the same range of PIDs as on ear‐lier kernels. On 32-bit platforms, 32768 is the maximum value for pid_max. On 64-bit systems, pid_max can be set to any value up to 2^22 (PID_MAX_LIMIT, approximately 4 million).
--------------------------------------------------------------------------

[Test Case]

1. making pid over 6 digits
#!/bin/bash

for i in {1..1000000}
do
  touch t
done

2. snap install --dangerous core_16-2.29.4.2_amd64.snap ( snap core 16-2.30 avoids using /proc/PID/cmdline, so need to use older version

3. you can see DENIED msgs in syslog

4. change /etc/apparmor.d/tunables/kernelvars
5. service apparmor restart
6. service snapd restart
7. DENIED is gone

This is one way, can't reproduce this issue again even if you change back to original kernelvars, and restart snapd

OR

instead of Seyeong's touch approach, things can be manually change to 7 digits range via sysctl as long as the values are below approximately 4 millions :

Example:
$ sysctl -w kernel.pid_max=3000000
$ sysctl -w kernel.ns_last_pid=1000000

[Regression]
* This is a minor/trivial fix which changes the pid regex only, allowing 7 digits PID instead of only 6 digits PID, we don't think there is any potential regression.

* If a regression arise, which we highly doubt, one can quickly revert the change manually and restart the service by modifying "/etc/apparmor.d/tunables/kernelvars" file to its original state (before this SRU).

[Others]

* Upstream commit:
 https://gitlab.com/apparmor/apparmor/commit/630cb2a981cdc731847e8fdaafc45bcd337fe747
http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/revision/3722

* Debian bug:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886732

* commit 630cb2a981cdc731847e8fdaafc45bcd337fe747
Author: Vincas Dargis <email address hidden>
Date: Sat Sep 30 15:28:15 2017 +0300

    Allow seven digit pid

* Affecting releases : TXZAB
--------------------------------------------------------------------------
$ git describe --contains 630cb2a9
v2.11.95~5^2

$ rmadison apparmor
 apparmor | 2.8.95~2430-0ubuntu5 | trusty
 apparmor | 2.10.95-0ubuntu2.6~14.04.1 | trusty-security
 apparmor | 2.10.95-0ubuntu2.6~14.04.1 | trusty-updates
 apparmor | 2.10.95-0ubuntu2 | xenial
 apparmor | 2.10.95-0ubuntu2.6 | xenial-security
 apparmor | 2.10.95-0ubuntu2.7 | xenial-updates
 apparmor | 2.11.0-2ubuntu4 | zesty
 apparmor | 2.11.0-2ubuntu17 | artful
 apparmor | 2.11.0-2ubuntu18 | bionic

$ rmadison -u debian apparmor
 apparmor | 2.11.1-4 | unstable
--------------------------------------------------------------------------

[Original Description]

If your kernel.pid_max sysctl is set higher than the default, say at 7 digits, the @{pid} variable no longer matches all pids, causing some breakage in any profile using it.

@{pid} is defined in /etc/apparmor.d/tunables:
@{pid}={[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9]}

It only covers up to 6 digits.

This Ubuntu 17.04 system has:
kernel.pid_max = 4194303

And is showing
type=1400 audit(1505588857.828:792): apparmor="DENIED" operation="open" profile="libvirt-55e9e12c-e6dc-4f56-a547-8514cf7d9bf3" name="/proc/2168180/task/2769256/comm" pid=2168180 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=111 ouid=111

Which should be matched by
@{PROC}/sys/vm/overcommit_memory r,
in /etc/apparmor.d/abstractions/libvirt-qemu

I'm seeing similar failures on 16.04 (2.10.95-0ubuntu2.7), 17.04 (2.11.0-2ubuntu4) and 17.10 (2.11.0-2ubuntu17)

I am aware this is a non-default configuration, but I think this should work.

Related branches

Andre Tomt (andre-tomt) wrote :

Sorry, a correction (copy paste error):
Which should be matched by
owner @{PROC}/@{pid}/task/[0-9]*/comm rw,
in /etc/apparmor.d/abstractions/libvirt-qemu

> I am aware this is a non-default configuration, but I think this should work.

Makes sense. Do you want to send a merge request?

Christian Boltz (cboltz) on 2017-09-18
tags: added: aa-policy
Vincas Dargis (talkless) wrote :

I can provide merge request, and I would like to suggest simplifying that ever-growing expression.

Couldn't it be just [0-9]*? Are there possibility that `/proc` will have some item, starting with digit, *not* being a pid?

On 09/25/2017 12:16 PM, Vincas Dargis wrote:
> I can provide merge request, and I would like to suggest simplifying
> that ever-growing expression.
>
> Couldn't it be just [0-9]*? Are there possibility that `/proc` will have
well it could but, its not as tight as I would like, ideally we could give
access to more than just apparmorre and make this tighter.

well actually ideally this will switch over to a kernel var, but that is
not ready yet

> some item, starting with digit, *not* being a pid?
>

I don't know of any atm, its possible but unlikely

Vincas Dargis (talkless) wrote :

OK, so if http://man7.org/linux/man-pages/man5/proc.5.html says:

```
On 64-bit systems, pid_max can be set to any value up to 2^22 (PID_MAX_LIMIT, approximately 4 million).
``

Its 4194304, so I will propose adding one more bulk of expressions for seven-digit PID, stating with [1-4].

Steve Beattie (sbeattie) wrote :
Changed in apparmor (Ubuntu):
status: New → Fix Committed
status: Fix Committed → Confirmed
Changed in apparmor:
status: New → Fix Committed
milestone: none → 2.12

The attachment "lp1717714_trusty.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Seyeong Kim (xtrusia) on 2018-01-09
description: updated
tags: added: sts-sru-needed
removed: patch
Changed in apparmor (Ubuntu):
assignee: nobody → Seyeong Kim (xtrusia)
Eric Desrochers (slashd) on 2018-01-09
description: updated
Eric Desrochers (slashd) wrote :

Hi Seyeong,

As we speak the LP build farm and autopkgtest request.cgi are disabled for maintenance; no ETA yet.
No new uploads are allowed during this temporary freeze cause by the maintenance.

We will gladly review your patch when everything will back to normal.

- Eric

Eric Desrochers (slashd) wrote :

Hi Seyeong,

Here's some sponsoring notes that will require minor change. While waiting for the build farm ...

#1 - Can you make sure (if not already) to forward/submit the patch to debian upstream against apparmor ? Which is a requirement for the patch to land in Ubuntu.

Then we can request a coredev to sponsor the devel release (bionic), and then start the SRU.

#2 - Seems like the good upstream commit number for the change is "ad94da321ba51e247b2df82a96cb9d83d47b887e" ? Can you double-check ?
If you confirm, please change the commit number where it applies.

#3 - Change "Origin:" in the DEP3 header
Origin: upstream, https://gitlab.com/apparmor/apparmor/commit/ad94da321ba51e247b2df82a96cb9d83d47b887e
(or using the proper commit (see #2))

#4 - Change "Bug-Ubuntu:" in DEP3 header using the short LP bug url

From
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1717714

To
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1717714

#5 - Review the package versions. Worst case I'll do it myself later when I'll be ready to upload.

Example taken from trusty debdiff:
Going from "2.10.95-0ubuntu2.6~14.04.1" to "2.10.95-0ubuntu2.7~14.04.1" is wrong. It's preferable to use "2.10.95-0ubuntu2.6~14.04.2"

Thanks & let me know if you have any questions.

- Eric

tags: added: sts-sponsor-slashd
Eric Desrochers (slashd) wrote :

I apologize, for #2 above in comment#14, the good commit containing the fix seems to be "630cb2a981cdc731847e8fdaafc45bcd337fe747", please make sure #3 "Origin:" reflect that.

- Eric

description: updated
description: updated
Eric Desrochers (slashd) wrote :

Not quite sure now if apparmor upstream is found in launchpad[1] or gitlab[2].

[1] https://launchpad.net/apparmor
[2] https://gitlab.com/apparmor

If it's launchpad then the URL is good.

If #2 & #3 are good (After your confirmation), then only #1, #4 and #5 are missing.

Im simply trying to anticipate & eliminate confusion before the final upload.

- Eric

Seyeong Kim (xtrusia) wrote :
Seyeong Kim (xtrusia) wrote :
Seyeong Kim (xtrusia) wrote :
Seyeong Kim (xtrusia) wrote :
Seyeong Kim (xtrusia) wrote :
Eric Desrochers (slashd) wrote :

Thanks Seyeong !

I'll do a 2nd review when the build farm will be back and will do the other changes if necessary.

- Eric

Eric Desrochers (slashd) wrote :

Meanwhile, please make sure you have submitted the patch to Debian and link the debbug in this LP.

- Eric

Changed in apparmor (Ubuntu Trusty):
assignee: nobody → Seyeong Kim (xtrusia)
Changed in apparmor (Ubuntu Xenial):
assignee: nobody → Seyeong Kim (xtrusia)
Changed in apparmor (Ubuntu Zesty):
assignee: nobody → Seyeong Kim (xtrusia)
Changed in apparmor (Ubuntu Artful):
assignee: nobody → Seyeong Kim (xtrusia)
Changed in apparmor (Ubuntu Trusty):
importance: Undecided → Medium
Changed in apparmor (Ubuntu Xenial):
importance: Undecided → Medium
Changed in apparmor (Ubuntu Zesty):
importance: Undecided → Medium
Changed in apparmor (Ubuntu Artful):
importance: Undecided → Medium
Changed in apparmor (Ubuntu Bionic):
importance: Undecided → Medium
Eric Desrochers (slashd) wrote :

I note that the Seyeong's Artful debdiff proposed version "2.11.0-2ubuntu18" and bionic "2.11.0-2ubuntu19"

# Current rmadison output
 apparmor | 2.11.0-2ubuntu17 | artful
 apparmor | 2.11.0-2ubuntu18 | bionic

Bionic version is good.

No need to change the debdiff, I'll do the change myself later, but I'm afraid for Artful we can't use the same version twice for 2 separate releases as it has, IMHO, high potential risk of rejection from SRU team.

I would go with that versionning approach instead:

apparmor | 2.11.0-2ubuntu17.1 | artful
apparmor | 2.11.0-2ubuntu19 | bionic

- Eric

Christian Boltz (cboltz) wrote :

> Not quite sure now if apparmor upstream is found in launchpad[1] or gitlab[2].

The code moved from bzr to gitlab recently. Bug tracking and translations are still handled on launchpad.

> I would go with that versionning approach instead:
>
> apparmor | 2.11.0-2ubuntu17.1 | artful
> apparmor | 2.11.0-2ubuntu19 | bionic

2.11.0? I'd seriously recommend to upgrade to 2.11.1 which has quite some bugfixes, see https://gitlab.com/apparmor/apparmor/wikis/Release_Notes_2.11.1
Note that the 7 digit pid patch was backported to the 2.11 branch after the 2.11.1 release, so you'll still need to apply this patch on top.

For bionic, you might even want to use 2.12.

Seyeong Kim (xtrusia) on 2018-01-12
description: updated
Eric Desrochers (slashd) on 2018-01-12
description: updated
Eric Desrochers (slashd) on 2018-01-12
description: updated
Eric Desrochers (slashd) wrote :

Attaching "lp1717714_bionic_V2.debdiff":
- Nitpicking stuff related to d/changelog and DEP3 patch header.

Eric Desrochers (slashd) wrote :

I have contacted a coredev to hopefully sponsor the development bit (Bionic) today, so I can proceed with the stable release update myself next week.

- Eric

Eric Desrochers (slashd) on 2018-01-12
Changed in apparmor (Ubuntu Bionic):
status: Confirmed → In Progress
Eric Desrochers (slashd) wrote :

bionic sponsoring done.

Thanks to sil2100.

Ill monitor the bionic build, and then start the SRU once everything good.

- Eric

Eric Desrochers (slashd) wrote :

Another verification that IMHO can be done more easily and faster than the touch approach explain above is to directly change the pid_max and ns_last_pid via sysctl in the 7 digit range (<4millions), and then try to reproducer.

For instance:
sysctl -w kernel.pid_max=3000000
sysctl -w kernel.ns_last_pid=1000000

- Eric

description: updated
Changed in apparmor (Debian):
status: Unknown → Confirmed
Eric Desrochers (slashd) on 2018-01-12
description: updated
Eric Desrochers (slashd) wrote :

The patch for bionic (devel release) has been sponsored but it is stuck in bionic-proposed for now waiting for the non amd64/i386 builder to be operational -> ppcel64, arm, s390x, ..

#rmadison
apparmor | 2.11.0-2ubuntu18 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
apparmor | 2.11.0-2ubuntu19 | bionic-proposed | source, amd64, i386

# Excuses page
apparmor (2.11.0-2ubuntu18 to 2.11.0-2ubuntu19)
Maintainer: Ubuntu Developers
2 days old
missing build on arm64: apparmor, apparmor-utils, libapache2-mod-apparmor, libapparmor-dev, libapparmor-perl, libapparmor1, libpam-apparmor, python-apparmor, python-libapparmor, python3-apparmor, python3-libapparmor (from 2.11.0-2ubuntu18)
missing build on armhf: apparmor, apparmor-utils, libapache2-mod-apparmor, libapparmor-dev, libapparmor-perl, libapparmor1, libpam-apparmor, python-apparmor, python-libapparmor, python3-apparmor, python3-libapparmor (from 2.11.0-2ubuntu18)
missing build on ppc64el: apparmor, apparmor-utils, libapache2-mod-apparmor, libapparmor-dev, libapparmor-perl, libapparmor1, libpam-apparmor, python-apparmor, python-libapparmor, python3-apparmor, python3-libapparmor (from 2.11.0-2ubuntu18)
missing build on s390x: apparmor, apparmor-utils, libapache2-mod-apparmor, libapparmor-dev, libapparmor-perl, libapparmor1, libpam-apparmor, python-apparmor, python-libapparmor, python3-apparmor, python3-libapparmor (from 2.11.0-2ubuntu18)
Not considered

Once everything is found in bionic release, I'll proceed with the Stable release sponsoring.

- Eric

intrigeri (intrigeri) wrote :

Eric Desrochers:
> The patch for bionic (devel release) has been sponsored but it is stuck in bionic-proposed for now waiting for the non amd64/i386 builder to be operational -> ppcel64, arm, s390x, ..

FWIW this patch is part of 2.12-1 that I've uploaded to Debian unstable.
No idea how exactly this will be sync'ed into Ubuntu.

Changed in apparmor (Debian):
status: Confirmed → Fix Released
Eric Desrochers (slashd) on 2018-01-16
Changed in apparmor (Ubuntu Bionic):
status: In Progress → Fix Committed
Eric Desrochers (slashd) on 2018-01-16
no longer affects: apparmor (Ubuntu Zesty)
Eric Desrochers (slashd) wrote :

About the "snapd/2.29.4.2+18.04" bionic/ppc64el regression.

# Excuses... page
autopkgtest for snapd/2.29.4.2+18.04: amd64: Ignored failure, arm64: Always failed, armhf: Pass, i386: Pass, ppc64el: Regression ♻ , s390x: Ignored failure

# Justification of the regression provided by mvo :
<mvo> the first error 2018-01-29 00:22:55 Error executing autopkgtest:ubuntu-18.04-ppc64el:tests/main/searching : is a store change
<mvo> our integration test fails because the snap store changed
<mvo> so just ignore
<mvo> I suspect the other ones are similar
<mvo> so please ask the sru team to ignore this error. with 2.31 (schedule in ~2weeks) the tests will be good again

- Eric

Eric Desrochers (slashd) wrote :

About "click-apparmor" bionic/armhf regression.

# Excuses... page
autopkgtest for click-apparmor/0.3.18: amd64: Pass, arm64: Pass, armhf: Regression ♻ , i386: Pass, ppc64el: Ignored failure, s390x: Always failed

After a discussion with security team and xnox. They are actively trying to remove this package from the archive, but it depends on things still at the moment. It was only used on touch which is RIP.

This regression can safely be ignore.

Regards,
Eric

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.11.0-2ubuntu19

---------------
apparmor (2.11.0-2ubuntu19) bionic; urgency=medium

  * d/p/0001-Allow-seven-digit-pid.patch:
    On 64bit systems, /proc/sys/kernel/pid_max can be set to PID_MAX_LIMIT,
    (2^22), which results in seven digit pids. Adjust the @{PID} variable in
    tunables/global to accept this. (LP: #1717714)

 -- Seyeong Kim <email address hidden> Mon, 08 Jan 2018 07:52:32 -0800

Changed in apparmor (Ubuntu Bionic):
status: Fix Committed → Fix Released
Eric Desrochers (slashd) on 2018-01-29
Changed in apparmor (Ubuntu Artful):
status: New → In Progress
Changed in apparmor (Ubuntu Xenial):
status: New → In Progress
Changed in apparmor (Ubuntu Trusty):
status: New → In Progress
Eric Desrochers (slashd) wrote :

Uploaded for T/X/A.

It is now waiting for the SRU verification team to approve the uploads for the packages to start building in -proposed.

- Eric

tags: added: sts-sponsor-slashd-done
removed: sts-sponsor-slashd

Hello Andre, or anyone else affected,

Accepted apparmor into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/2.11.0-2ubuntu17.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in apparmor (Ubuntu Artful):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-artful
Changed in apparmor (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed-xenial
Łukasz Zemczak (sil2100) wrote :

Hello Andre, or anyone else affected,

Accepted apparmor into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/2.10.95-0ubuntu2.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Łukasz Zemczak (sil2100) wrote :

Hello Andre, or anyone else affected,

Accepted apparmor into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/2.10.95-0ubuntu2.6~14.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in apparmor (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed-trusty
Seyeong Kim (xtrusia) wrote :

Hello, I tested on xenial

ii apparmor 2.10.95-0ubuntu2.8

tested same steps as test case section.

there is no DENIED after installing proposed pkg

Thanks

tags: added: verification-done-xenial
removed: verification-needed-xenial
Seyeong Kim (xtrusia) wrote :

Hello, I tested on artful

ii apparmor 2.11.0-2ubuntu17.1

tested same steps as test case section.

Thanks

tags: added: verification-done-artful
removed: verification-needed-artful
Seyeong Kim (xtrusia) wrote :

Hello

on trusty

apt-get download apparmor_2.10.95-0ubuntu2.6~14.04.2_amd64.ddb

dpkg -x apparmor... t

cat t/etc/apparmor.d/tunables/kernelvars

@{pid}={[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9]}

which is old one.

I checked apt-get source

There is correct file.

Could you please this one more time?

Thanks.

tags: added: verification-failed-trusty
removed: verification-needed-trusty
Eric Desrochers (slashd) wrote :

Hi Seyeong,

I did some verification this morning based on your comment #42.

After some digging... it turns out that the profiles in "apparmor_src_pkg/profiles/" are not used. if you are attempting to patch a profile, you must adjust it to patch apparmor_src_pkg/profiles-14.04/ instead.

In this particular case "apparmor-src-pkg/profiles-14.04/apparmor.d/tunables/kernelvars" instead of "apparmor-pkg-src/profiles/apparmor.d/tunables/kernelvars".

You did the right thing by putting the bug to verification-failed-trusty.

As of the next step ... I would recommend you re-do the patch considering the above, and pay attention this time that the change is taken into account in your pkg PPA build, then test your reproducer against the package, make sure it works as expected.

Once everything is confirm on your side, I'll double-check one more time before the proceeding the next upload.

- Eric

Eric Desrochers (slashd) on 2018-02-02
tags: added: regression-proposed-trusty
tags: removed: regression-proposed-trusty
Eric Desrochers (slashd) wrote :

I have re-did the SRU by renaming/modifying the existing patch to adapt to the profile-14.04.

[VALIDATION PRE-UPLOAD]

# dpkg -l | grep -i apparmor
ii apparmor 2.10.95-0ubuntu2.6~14.04.3 amd64 user-space parser utility for AppArmor
ii libapparmor-perl 2.10.95-0ubuntu2.6~14.04.1 amd64 AppArmor library Perl bindings
ii libapparmor1:amd64 2.10.95-0ubuntu2.6~14.04.1 amd64 changehat AppArmor library

# grep "@{pid}=" /etc/apparmor.d/tunables/kernelvars | grep -v "#"
@{pid}={[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9],[1-4][0-9][0-9][0-9][0-9][0-9][0-9]}

# diff -u /tmp/kernelvars_2.10.95-0ubuntu2.6~14.04.2 /tmp/kernelvars_2.10.95-0ubuntu2.6~14.04.3
--- /tmp/kernelvars_2.10.95-0ubuntu2.6~14.04.2 2018-02-02 16:13:34.391910246 +0000
+++ /tmp/kernelvars_2.10.95-0ubuntu2.6~14.04.3 2018-02-02 16:14:25.880489983 +0000
@@ -13,7 +13,7 @@
 # and until the parser supports nested groupings like
 # @{pid}=[1-9]{[0-9]{[0-9]{[0-9]{[0-9]{[0-9],},},},},}
 # use
-@{pid}={[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9]}
+@{pid}={[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9],[1-4][0-9][0-9][0-9][0-9][0-9][0-9]}

 #same pattern as @{pid} for now
 @{tid}=@{pid}

The above confirm that the patch is now taking into account as it should.

- Eric

Eric Desrochers (slashd) wrote :

profile-14.04-trusty-lp1717714.debdiff

Eric Desrochers (slashd) wrote :

Got a confirmation by SRU verification that the new debdiff was SRU'able.
I have uploaded V2 a few minutes ago. It is now waiting on SRU team for approval and then should land in trusty-proposed.

- Eric

Changed in apparmor (Ubuntu Trusty):
status: Fix Committed → In Progress
assignee: Seyeong Kim (xtrusia) → Eric Desrochers (slashd)
Łukasz Zemczak (sil2100) wrote :

Hello Andre, or anyone else affected,

Accepted apparmor into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/2.10.95-0ubuntu2.6~14.04.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in apparmor (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed-trusty
removed: verification-failed-trusty
Seyeong Kim (xtrusia) wrote :

Thanks Eric

ii apparmor 2.10.95-0ubuntu2.6~14.04.3

there is no pre-installed snapd on trusty so i needed to install snapd first

1. set sysctl
2. add -proposed
3. apt install snapd
4. reboot
5. snap install --dangerous oldverioncore

symptom is gone

Thanks.

tags: added: verification-done-trusty
removed: verification-needed-trusty
Eric Desrochers (slashd) wrote :

Hi Seyeong,

The regression found in pending sru for apparmor (xenial):

Regression in autopkgtest for snapd (ppc64el): test log
Regression in autopkgtest for snapd (amd64): test log

and apparmor (artful):

Regression in autopkgtest for snapd (ppc64el): test log
Regression in autopkgtest for snapd (s390x): test log
Regression in autopkgtest for snapd (amd64): test log
Regression in autopkgtest for snapd (i386): test log

Seems similar to the following statement made by mvo :
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1717714/comments/33

Hopefully the new snapd version should fix the store changes ...

But feel free to contact mvo for more details about these regressions and see if they can safely ignore or not before asking sru team to release in -updates.

- Eric

Seyeong Kim (xtrusia) wrote :

Hello Eric

I'm attaching mvo's PM

mvo: yes, please ignore the failure of snapd. there was a server side change in the store that makes the autopkgtests fail

Seyeong Kim (xtrusia) wrote :

sorry not commenting at once

mvo: the almost-ready 2.31 release will fix this

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.11.0-2ubuntu17.1

---------------
apparmor (2.11.0-2ubuntu17.1) artful; urgency=medium

  * d/p/0001-Allow-seven-digit-pid.patch:
    On 64bit systems, /proc/sys/kernel/pid_max can be set to PID_MAX_LIMIT,
    (2^22), which results in seven digit pids. Adjust the @{PID} variable in
    tunables/global to accept this. (LP: #1717714)

 -- Seyeong Kim <email address hidden> Mon, 08 Jan 2018 07:49:55 -0800

Changed in apparmor (Ubuntu Artful):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for apparmor has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.8

---------------
apparmor (2.10.95-0ubuntu2.8) xenial; urgency=medium

  * d/p/0001-Allow-seven-digit-pid.patch:
    On 64bit systems, /proc/sys/kernel/pid_max can be set to PID_MAX_LIMIT,
    (2^22), which results in seven digit pids. Adjust the @{PID} variable in
    tunables/global to accept this. (LP: #1717714)

 -- Seyeong Kim <email address hidden> Mon, 08 Jan 2018 07:43:46 -0800

Changed in apparmor (Ubuntu Xenial):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.6~14.04.3

---------------
apparmor (2.10.95-0ubuntu2.6~14.04.3) trusty; urgency=medium

  * d/p/14.04-profiles-allow-seven-digit-pid-lp1717714.patch:
    - Renamed d/p/0001-Allow-seven-digit-pid.patch to mirror other
      profiles-14.04 patches naming pattern.
    - Modify the existing/renamed patch to use the dir that should be use to
      patch a profile. profiles-14.04/ should be use instead of profiles/
      which is not use. (LP: #1717714)

 -- Eric Desrochers <email address hidden> Fri, 02 Feb 2018 10:19:38 -0500

Changed in apparmor (Ubuntu Trusty):
status: Fix Committed → Fix Released
Christian Boltz (cboltz) on 2018-04-22
Changed in apparmor:
status: Fix Committed → Fix Released
tags: removed: sts-sru-needed verification-needed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.