[Touch-packages] [Bug 1558753] Re: AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based)
Hello, I'm having the same issue in 18.04 as well, also fixed it by adding `/var/lib/sss/pipes/private/pam wr,` to `/etc/apparmor.d/local/usr.sbin.cupsd`. Confirmed both the issue and fix on 2 different machines (both on 18.04) and with 2 different AD accounts. -- 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/1558753 Title: AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based) Status in AppArmor: New Status in apparmor package in Ubuntu: Confirmed Bug description: System information: OS: Ubuntu 14.04.4 LTS AppArmor 2.8.95~2430-0ubuntu5.3 SSSD: 1.11.5-1ubuntu3 CUPS: 1.7.2-0ubuntu1.7 I believe this is a bug that belongs here rather than with SSSD or CUPS package; apologies if incorrect. The problem arises when attempting to grant non-local end user accounts (e.g, domain accounts) extra permissions to modify portions of the Admin page, so that they can add/remove printers themselves for instance. There's a few ways to do this, obviously, such as adding extra groups or users to the SystemGroup definition in /etc/cups- files, or adding "Require valid-user" to the location in /etc/cupsd.conf. Attempting to alter SystemGroup by adding "Domain Users", or by adding the "Require valid-user" statement to the /admin location definition causes the CUPS web page (http://localhost:631) to reject all network users credentials. The valid-user option will cause CUPS to accept local user account credentials regardless of whether they have root access or are part of lpadmin. Interestingly, both BasicAuthentication and Kerberos (Negotiate) authentication modes cause network accounts to be rejected . Digging through logs, it becomes apparent that CUPS appears to rely on PAM for authentication - error messages appear in /var/log/auth.log like so: Mar 15 07:53:41 cupsd: pam_unix(cups:auth): authentication failure; logname= uid=0 euid=0 tty=cups ruser= rhost=localhost user= Mar 15 07:53L31 cupsd: pam_sss(cups:auth): Request to sssd failed. Permission denied The first line is expected, as a network account will not be auth'd by pam_unix. The second line points to the problem: when CUPS attempts to talk to sssd (indirectly by invoking PAM, but it still happens) then CUPS is blocked with a permission denied. Further research turned up a prior bug report (1264548, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1264548) that highlighted nearly the same problem and highlighting it as an AppArmor rejection. Examining the output of `dmesg | grepDENIED.*cups`, we do see lines in the output: [21507.848482] type=1400 audit(1458067443.626:435): apparmor="DENIED" operation="connect" profile="/usr/sbin/cupsd" name="/var/lib/sss/pipes/private/pam" pid=27447 comm="cupsd" requested_mask="rw" denied_mask="rw" fsuid=0 ouid=0 Further evidence can be found in the fact that setting the CUPS profile to complain mode in AppArmor causes the problem to go away (both Kerberos and Basic authentication modes work). I have successfully resolved the issue locally by adding the rule /var/lib/sss/pipes/private/pam rw, to the file /etc/apparmor.d/local/usr.sbin.cupsd. Interestingly, this also resolves the kerberos issue - both 'DefaultAuthType Basic' and 'DefaultAuthType Negotiate' will successfully allow network accounts to access the Administration page. Looking at /etc/apparmor.d/usr.sbin.cupsd, it includes the abstractions/authentication def file, which in turn contains a specific include for the abstractions/winbind file. I don't know whether there should be an equivalent abstractions file for sssd; the one line fix above really doesn't by itself warrant a full separate file, but if there are perhaps other sssd specific definitions that contained applications may need access to, perhaps that would warrant a separate file. I also don't know what, if any, wider security issues there may be from granting CUPS access to /var/lib/sss/pipes/private/pam, either, so perhaps a different proper fix would be required? To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1558753/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1558753] Re: AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based)
ubuntu 18.04 pam_sss(cups:auth): Request to sssd failed. Permission denied likely same issue. -- 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/1558753 Title: AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based) Status in AppArmor: New Status in apparmor package in Ubuntu: Confirmed Bug description: System information: OS: Ubuntu 14.04.4 LTS AppArmor 2.8.95~2430-0ubuntu5.3 SSSD: 1.11.5-1ubuntu3 CUPS: 1.7.2-0ubuntu1.7 I believe this is a bug that belongs here rather than with SSSD or CUPS package; apologies if incorrect. The problem arises when attempting to grant non-local end user accounts (e.g, domain accounts) extra permissions to modify portions of the Admin page, so that they can add/remove printers themselves for instance. There's a few ways to do this, obviously, such as adding extra groups or users to the SystemGroup definition in /etc/cups- files, or adding "Require valid-user" to the location in /etc/cupsd.conf. Attempting to alter SystemGroup by adding "Domain Users", or by adding the "Require valid-user" statement to the /admin location definition causes the CUPS web page (http://localhost:631) to reject all network users credentials. The valid-user option will cause CUPS to accept local user account credentials regardless of whether they have root access or are part of lpadmin. Interestingly, both BasicAuthentication and Kerberos (Negotiate) authentication modes cause network accounts to be rejected . Digging through logs, it becomes apparent that CUPS appears to rely on PAM for authentication - error messages appear in /var/log/auth.log like so: Mar 15 07:53:41 cupsd: pam_unix(cups:auth): authentication failure; logname= uid=0 euid=0 tty=cups ruser= rhost=localhost user= Mar 15 07:53L31 cupsd: pam_sss(cups:auth): Request to sssd failed. Permission denied The first line is expected, as a network account will not be auth'd by pam_unix. The second line points to the problem: when CUPS attempts to talk to sssd (indirectly by invoking PAM, but it still happens) then CUPS is blocked with a permission denied. Further research turned up a prior bug report (1264548, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1264548) that highlighted nearly the same problem and highlighting it as an AppArmor rejection. Examining the output of `dmesg | grepDENIED.*cups`, we do see lines in the output: [21507.848482] type=1400 audit(1458067443.626:435): apparmor="DENIED" operation="connect" profile="/usr/sbin/cupsd" name="/var/lib/sss/pipes/private/pam" pid=27447 comm="cupsd" requested_mask="rw" denied_mask="rw" fsuid=0 ouid=0 Further evidence can be found in the fact that setting the CUPS profile to complain mode in AppArmor causes the problem to go away (both Kerberos and Basic authentication modes work). I have successfully resolved the issue locally by adding the rule /var/lib/sss/pipes/private/pam rw, to the file /etc/apparmor.d/local/usr.sbin.cupsd. Interestingly, this also resolves the kerberos issue - both 'DefaultAuthType Basic' and 'DefaultAuthType Negotiate' will successfully allow network accounts to access the Administration page. Looking at /etc/apparmor.d/usr.sbin.cupsd, it includes the abstractions/authentication def file, which in turn contains a specific include for the abstractions/winbind file. I don't know whether there should be an equivalent abstractions file for sssd; the one line fix above really doesn't by itself warrant a full separate file, but if there are perhaps other sssd specific definitions that contained applications may need access to, perhaps that would warrant a separate file. I also don't know what, if any, wider security issues there may be from granting CUPS access to /var/lib/sss/pipes/private/pam, either, so perhaps a different proper fix would be required? To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1558753/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1558753] Re: AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based)
Hi Tyler, we are experiencing this issue with a similar production environment. Can I submit our configurations to help with investigating this issue further? Please let me know. Regards, -- 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/1558753 Title: AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based) Status in AppArmor: New Status in apparmor package in Ubuntu: Confirmed Bug description: System information: OS: Ubuntu 14.04.4 LTS AppArmor 2.8.95~2430-0ubuntu5.3 SSSD: 1.11.5-1ubuntu3 CUPS: 1.7.2-0ubuntu1.7 I believe this is a bug that belongs here rather than with SSSD or CUPS package; apologies if incorrect. The problem arises when attempting to grant non-local end user accounts (e.g, domain accounts) extra permissions to modify portions of the Admin page, so that they can add/remove printers themselves for instance. There's a few ways to do this, obviously, such as adding extra groups or users to the SystemGroup definition in /etc/cups- files, or adding "Require valid-user" to the location in /etc/cupsd.conf. Attempting to alter SystemGroup by adding "Domain Users", or by adding the "Require valid-user" statement to the /admin location definition causes the CUPS web page (http://localhost:631) to reject all network users credentials. The valid-user option will cause CUPS to accept local user account credentials regardless of whether they have root access or are part of lpadmin. Interestingly, both BasicAuthentication and Kerberos (Negotiate) authentication modes cause network accounts to be rejected . Digging through logs, it becomes apparent that CUPS appears to rely on PAM for authentication - error messages appear in /var/log/auth.log like so: Mar 15 07:53:41 cupsd: pam_unix(cups:auth): authentication failure; logname= uid=0 euid=0 tty=cups ruser= rhost=localhost user= Mar 15 07:53L31 cupsd: pam_sss(cups:auth): Request to sssd failed. Permission denied The first line is expected, as a network account will not be auth'd by pam_unix. The second line points to the problem: when CUPS attempts to talk to sssd (indirectly by invoking PAM, but it still happens) then CUPS is blocked with a permission denied. Further research turned up a prior bug report (1264548, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1264548) that highlighted nearly the same problem and highlighting it as an AppArmor rejection. Examining the output of `dmesg | grepDENIED.*cups`, we do see lines in the output: [21507.848482] type=1400 audit(1458067443.626:435): apparmor="DENIED" operation="connect" profile="/usr/sbin/cupsd" name="/var/lib/sss/pipes/private/pam" pid=27447 comm="cupsd" requested_mask="rw" denied_mask="rw" fsuid=0 ouid=0 Further evidence can be found in the fact that setting the CUPS profile to complain mode in AppArmor causes the problem to go away (both Kerberos and Basic authentication modes work). I have successfully resolved the issue locally by adding the rule /var/lib/sss/pipes/private/pam rw, to the file /etc/apparmor.d/local/usr.sbin.cupsd. Interestingly, this also resolves the kerberos issue - both 'DefaultAuthType Basic' and 'DefaultAuthType Negotiate' will successfully allow network accounts to access the Administration page. Looking at /etc/apparmor.d/usr.sbin.cupsd, it includes the abstractions/authentication def file, which in turn contains a specific include for the abstractions/winbind file. I don't know whether there should be an equivalent abstractions file for sssd; the one line fix above really doesn't by itself warrant a full separate file, but if there are perhaps other sssd specific definitions that contained applications may need access to, perhaps that would warrant a separate file. I also don't know what, if any, wider security issues there may be from granting CUPS access to /var/lib/sss/pipes/private/pam, either, so perhaps a different proper fix would be required? To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1558753/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1558753] Re: AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based)
Still a problem in 16.04 LTS. Workaround is simply "aa-complain cupsd" but that's kind of crummy... -- 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/1558753 Title: AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based) Status in AppArmor: New Status in apparmor package in Ubuntu: Confirmed Bug description: System information: OS: Ubuntu 14.04.4 LTS AppArmor 2.8.95~2430-0ubuntu5.3 SSSD: 1.11.5-1ubuntu3 CUPS: 1.7.2-0ubuntu1.7 I believe this is a bug that belongs here rather than with SSSD or CUPS package; apologies if incorrect. The problem arises when attempting to grant non-local end user accounts (e.g, domain accounts) extra permissions to modify portions of the Admin page, so that they can add/remove printers themselves for instance. There's a few ways to do this, obviously, such as adding extra groups or users to the SystemGroup definition in /etc/cups- files, or adding "Require valid-user" to the location in /etc/cupsd.conf. Attempting to alter SystemGroup by adding "Domain Users", or by adding the "Require valid-user" statement to the /admin location definition causes the CUPS web page (http://localhost:631) to reject all network users credentials. The valid-user option will cause CUPS to accept local user account credentials regardless of whether they have root access or are part of lpadmin. Interestingly, both BasicAuthentication and Kerberos (Negotiate) authentication modes cause network accounts to be rejected . Digging through logs, it becomes apparent that CUPS appears to rely on PAM for authentication - error messages appear in /var/log/auth.log like so: Mar 15 07:53:41 cupsd: pam_unix(cups:auth): authentication failure; logname= uid=0 euid=0 tty=cups ruser= rhost=localhost user= Mar 15 07:53L31 cupsd: pam_sss(cups:auth): Request to sssd failed. Permission denied The first line is expected, as a network account will not be auth'd by pam_unix. The second line points to the problem: when CUPS attempts to talk to sssd (indirectly by invoking PAM, but it still happens) then CUPS is blocked with a permission denied. Further research turned up a prior bug report (1264548, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1264548) that highlighted nearly the same problem and highlighting it as an AppArmor rejection. Examining the output of `dmesg | grepDENIED.*cups`, we do see lines in the output: [21507.848482] type=1400 audit(1458067443.626:435): apparmor="DENIED" operation="connect" profile="/usr/sbin/cupsd" name="/var/lib/sss/pipes/private/pam" pid=27447 comm="cupsd" requested_mask="rw" denied_mask="rw" fsuid=0 ouid=0 Further evidence can be found in the fact that setting the CUPS profile to complain mode in AppArmor causes the problem to go away (both Kerberos and Basic authentication modes work). I have successfully resolved the issue locally by adding the rule /var/lib/sss/pipes/private/pam rw, to the file /etc/apparmor.d/local/usr.sbin.cupsd. Interestingly, this also resolves the kerberos issue - both 'DefaultAuthType Basic' and 'DefaultAuthType Negotiate' will successfully allow network accounts to access the Administration page. Looking at /etc/apparmor.d/usr.sbin.cupsd, it includes the abstractions/authentication def file, which in turn contains a specific include for the abstractions/winbind file. I don't know whether there should be an equivalent abstractions file for sssd; the one line fix above really doesn't by itself warrant a full separate file, but if there are perhaps other sssd specific definitions that contained applications may need access to, perhaps that would warrant a separate file. I also don't know what, if any, wider security issues there may be from granting CUPS access to /var/lib/sss/pipes/private/pam, either, so perhaps a different proper fix would be required? To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1558753/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1558753] Re: AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based)
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. https://bugs.launchpad.net/bugs/1558753 Title: AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based) Status in AppArmor: New Status in apparmor package in Ubuntu: Confirmed Bug description: System information: OS: Ubuntu 14.04.4 LTS AppArmor 2.8.95~2430-0ubuntu5.3 SSSD: 1.11.5-1ubuntu3 CUPS: 1.7.2-0ubuntu1.7 I believe this is a bug that belongs here rather than with SSSD or CUPS package; apologies if incorrect. The problem arises when attempting to grant non-local end user accounts (e.g, domain accounts) extra permissions to modify portions of the Admin page, so that they can add/remove printers themselves for instance. There's a few ways to do this, obviously, such as adding extra groups or users to the SystemGroup definition in /etc/cups- files, or adding "Require valid-user" to the location in /etc/cupsd.conf. Attempting to alter SystemGroup by adding "Domain Users", or by adding the "Require valid-user" statement to the /admin location definition causes the CUPS web page (http://localhost:631) to reject all network users credentials. The valid-user option will cause CUPS to accept local user account credentials regardless of whether they have root access or are part of lpadmin. Interestingly, both BasicAuthentication and Kerberos (Negotiate) authentication modes cause network accounts to be rejected . Digging through logs, it becomes apparent that CUPS appears to rely on PAM for authentication - error messages appear in /var/log/auth.log like so: Mar 15 07:53:41 cupsd: pam_unix(cups:auth): authentication failure; logname= uid=0 euid=0 tty=cups ruser= rhost=localhost user= Mar 15 07:53L31 cupsd: pam_sss(cups:auth): Request to sssd failed. Permission denied The first line is expected, as a network account will not be auth'd by pam_unix. The second line points to the problem: when CUPS attempts to talk to sssd (indirectly by invoking PAM, but it still happens) then CUPS is blocked with a permission denied. Further research turned up a prior bug report (1264548, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1264548) that highlighted nearly the same problem and highlighting it as an AppArmor rejection. Examining the output of `dmesg | grepDENIED.*cups`, we do see lines in the output: [21507.848482] type=1400 audit(1458067443.626:435): apparmor="DENIED" operation="connect" profile="/usr/sbin/cupsd" name="/var/lib/sss/pipes/private/pam" pid=27447 comm="cupsd" requested_mask="rw" denied_mask="rw" fsuid=0 ouid=0 Further evidence can be found in the fact that setting the CUPS profile to complain mode in AppArmor causes the problem to go away (both Kerberos and Basic authentication modes work). I have successfully resolved the issue locally by adding the rule /var/lib/sss/pipes/private/pam rw, to the file /etc/apparmor.d/local/usr.sbin.cupsd. Interestingly, this also resolves the kerberos issue - both 'DefaultAuthType Basic' and 'DefaultAuthType Negotiate' will successfully allow network accounts to access the Administration page. Looking at /etc/apparmor.d/usr.sbin.cupsd, it includes the abstractions/authentication def file, which in turn contains a specific include for the abstractions/winbind file. I don't know whether there should be an equivalent abstractions file for sssd; the one line fix above really doesn't by itself warrant a full separate file, but if there are perhaps other sssd specific definitions that contained applications may need access to, perhaps that would warrant a separate file. I also don't know what, if any, wider security issues there may be from granting CUPS access to /var/lib/sss/pipes/private/pam, either, so perhaps a different proper fix would be required? To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1558753/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1558753] Re: AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based)
Hi Doug - Thank you for the excellent bug report! Since we're preparing for the upstream AppArmor 2.11 release, I took a look to see if I could fix this bug prior to the release. Unfortunately, I didn't have time to get to the bottom of what the significance is of the private (sometimes referred to as privileged in the source code) pipe is. Without understanding the importance of the pipe, I didn't want to rush into granting access from cupsd. I'm glad that you have a workaround to unblock yourself and I hope that we can better understand the usage of that particular pipe to make a judgement call on adding the rule in the upstream policy. Thanks again! ** Also affects: apparmor Importance: Undecided Status: New ** Tags added: aa-policy -- 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/1558753 Title: AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based) Status in AppArmor: New Status in apparmor package in Ubuntu: New Bug description: System information: OS: Ubuntu 14.04.4 LTS AppArmor 2.8.95~2430-0ubuntu5.3 SSSD: 1.11.5-1ubuntu3 CUPS: 1.7.2-0ubuntu1.7 I believe this is a bug that belongs here rather than with SSSD or CUPS package; apologies if incorrect. The problem arises when attempting to grant non-local end user accounts (e.g, domain accounts) extra permissions to modify portions of the Admin page, so that they can add/remove printers themselves for instance. There's a few ways to do this, obviously, such as adding extra groups or users to the SystemGroup definition in /etc/cups- files, or adding "Require valid-user" to the location in /etc/cupsd.conf. Attempting to alter SystemGroup by adding "Domain Users", or by adding the "Require valid-user" statement to the /admin location definition causes the CUPS web page (http://localhost:631) to reject all network users credentials. The valid-user option will cause CUPS to accept local user account credentials regardless of whether they have root access or are part of lpadmin. Interestingly, both BasicAuthentication and Kerberos (Negotiate) authentication modes cause network accounts to be rejected . Digging through logs, it becomes apparent that CUPS appears to rely on PAM for authentication - error messages appear in /var/log/auth.log like so: Mar 15 07:53:41 cupsd: pam_unix(cups:auth): authentication failure; logname= uid=0 euid=0 tty=cups ruser= rhost=localhost user= Mar 15 07:53L31 cupsd: pam_sss(cups:auth): Request to sssd failed. Permission denied The first line is expected, as a network account will not be auth'd by pam_unix. The second line points to the problem: when CUPS attempts to talk to sssd (indirectly by invoking PAM, but it still happens) then CUPS is blocked with a permission denied. Further research turned up a prior bug report (1264548, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1264548) that highlighted nearly the same problem and highlighting it as an AppArmor rejection. Examining the output of `dmesg | grepDENIED.*cups`, we do see lines in the output: [21507.848482] type=1400 audit(1458067443.626:435): apparmor="DENIED" operation="connect" profile="/usr/sbin/cupsd" name="/var/lib/sss/pipes/private/pam" pid=27447 comm="cupsd" requested_mask="rw" denied_mask="rw" fsuid=0 ouid=0 Further evidence can be found in the fact that setting the CUPS profile to complain mode in AppArmor causes the problem to go away (both Kerberos and Basic authentication modes work). I have successfully resolved the issue locally by adding the rule /var/lib/sss/pipes/private/pam rw, to the file /etc/apparmor.d/local/usr.sbin.cupsd. Interestingly, this also resolves the kerberos issue - both 'DefaultAuthType Basic' and 'DefaultAuthType Negotiate' will successfully allow network accounts to access the Administration page. Looking at /etc/apparmor.d/usr.sbin.cupsd, it includes the abstractions/authentication def file, which in turn contains a specific include for the abstractions/winbind file. I don't know whether there should be an equivalent abstractions file for sssd; the one line fix above really doesn't by itself warrant a full separate file, but if there are perhaps other sssd specific definitions that contained applications may need access to, perhaps that would warrant a separate file. I also don't know what, if any, wider security issues there may be from granting CUPS access to /var/lib/sss/pipes/private/pam, either, so perhaps a different proper fix would be required? To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1558753/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-pa
