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

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?

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

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].

Fix committed upstream in http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/revision/3722.

Thanks!

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.]

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

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

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

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

Thanks Seyeong !

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

- Eric

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

- Eric

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

> 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.

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

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

bionic sponsoring done.

Thanks to sil2100.

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

- Eric

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

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

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.

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

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

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

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

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!

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!

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!

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

Hello, I tested on artful

ii apparmor 2.11.0-2ubuntu17.1

tested same steps as test case section.

Thanks

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.

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

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

profile-14.04-trusty-lp1717714.debdiff

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

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!

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.

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

pending sru url -> https://people.canonical.com/~ubuntu-archive/pending-sru.html

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

sorry not commenting at once

mvo: the almost-ready 2.31 release will fix this

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

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.

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

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