[rationale]
Systems using sssd experience issue when software runder under apparmor tries to access the authentication cache.
[test case]
1) Setup a system using sssd
2) Restart cups (for example)
3) Check that DENIED lines appear in dmesg for /var/lib/sss/mc/*
4) Update apparmor
5) Flush dmesg (dmesg -c)
6) Restart cups (for example)
7) Confirm that the DENIED entries no longer appear
[regression potential]
Trivial change, allowing read access to an extra two files, don't see any potential regression here. Worst case scenario would be that the software currently impacted by this will crash later on because of another missing rule. So far on my test systems, I haven't seen any such behaviour and even so, it technically wouldn't be a regression but just something else needing fixing.
sssd provides two files for fast access to its cache, /var/lib/sss/mc/group and /var/lib/sss/mc/passwd.
Those are world readable and any process susceptible of doing nss queries should be allowed read rights to these.
=== modified file 'profiles/apparmor.d/abstractions/nameservice'
--- profiles/apparmor.d/abstractions/nameservice 2012-01-12 12:55:17 +0000
+++ profiles/apparmor.d/abstractions/nameservice 2012-09-25 18:44:33 +0000
@@ -21,6 +21,10 @@
/etc/passwd r,
/etc/protocols r,
+ # When using sssd, the passwd and group files are stored in an alternate path
+ /var/lib/sss/mc/group r,
+ /var/lib/sss/mc/passwd r,
+
/etc/resolv.conf r,
# on systems using resolvconf, /etc/resolv.conf is a symlink to
# /{,var/}run/resolvconf/resolv.conf and a file sometimes referenced in
The fix above seems to be doing the trick here, it's similar to the selinux rule change that had to happen on redhat's side:
https://bugzilla.redhat.com/show_bug.cgi?id=806348
As I'm mostly using sssd on 12.04 systems, I'm going to also prepare an SRU for this.