http://bugzilla.opensuse.org/show_bug.cgi?id=1195463 http://bugzilla.opensuse.org/show_bug.cgi?id=1195463#c16 --- Comment #16 from Noel Power <nopower@suse.com> --- (In reply to Christian Boltz from comment #15)
(In reply to Noel Power from comment #13)
Hi Christian, I reproduced this, better still I think I can keep on reproducing it thanks to a vm (snapshotted before/after)
Sounds promising :-) and even if I don't yet know exactly what's going on, that should help with debugging.
this is Leap 15.4 (not probably fully updated) but I attempted to update with https://build.opensuse.org/package/show/home:npower:branches:security: apparmor/apparmor (adjusts apparmor with /proc/{pipd}/fd rule)
Looks good, feel free to send a SR ;-)
right, hehe I was in the middle of doing that and testing when I got the lucky break of (hopefully) being able to consistently have this fail see https://build.opensuse.org/request/show/964827
What is happening is the cached file /etc/apparmor.d/cache.d/*/samba-bgqd doesn't appear to be updated correctly with the install on system
Just for the records: on openSUSE, /etc/apparmor.d/cache.d/ is a symlink to /var/cache/apparmor/ (IIRC some other distros have the cache directly in /etc/apparmor.d/cache.d/)
oh yeah, I already realised this when I expanded the tar ball on another machine to look at it and the cache.d contents were completely different to what I was expecting :-)
I'll paste the relevant files/timestamps from the tarball (ignoring abstractions for now) in a slightly more readable format:
Mar 23 16:51 ./etc/apparmor.d/samba-bgqd Mar 23 16:51 ./etc/apparmor.d/local/samba-bgqd Mar 23 16:50 ./usr/share/apparmor/cache/d29c4283.0/samba-bgqd Mar 23 21:43 ./var/cache/apparmor/d29c4283.0/samba-bgqd
This means: - the packaged cache in /usr/ has a too-old timestamp (that's a packaging bug, and I have a solution mostly ready - just waiting for an upstream answer for a detail question) - the locally generated cache in /var/ looks new enough (clearly newer than the profile in /etc/)
but it *did* update it (see date)
Indeed, and that's the strange part.
if I stop apparmor, remove /etc/apparmor.d/cache.d/d29c4283.0/samba-bgqd and restart the cache file size matches /usr/share/apparmor/cache/d29c4283.0/samba-bgqd and I no longer get the DENIED for /proc/{pipd}/fd
Just deleting the cache file in /var/ + rcapparmor reload should be enough - no need to stop apparmor.
good to know, hehe I am a hammer for everything kinda guy
I will attach a tarball with the data you requested. Let me know if you need any other info and/or debugging I can do to help
Just to be sure - does your tarball contain the "broken" or the "working" cache?
tar ball contains detail of broken cache file (note though the version of my package is slightly older (doesn't include the openssl bit)
I'd also be interested in an audit.log that includes reloading the samba-bgqd profile multiple times and in multiple cases? Please first read the "Crazy idea" at the end, then run
I'll look at this on Tue when I am back from vacation :->
sha256sum /var/cache/apparmor/*/samba-bgqd >> /var/log/audit/audit.log rcapparmor reload sha256sum /var/cache/apparmor/*/samba-bgqd >> /var/log/audit/audit.log echo "zypper up" >> /var/log/audit/audit.log zypper up # or whatever you need to install your updated AppArmor packages sha256sum /var/cache/apparmor/*/samba-bgqd >> /var/log/audit/audit.log rcapparmor reload sha256sum /var/cache/apparmor/*/samba-bgqd >> /var/log/audit/audit.log echo "samba-bgqd cache deleted" >> /var/log/audit/audit.log rm -v /var/cache/apparmor/*/samba-bgqd >> /var/log/audit/audit.log rcapparmor reload sha256sum /var/cache/apparmor/*/samba-bgqd >> /var/log/audit/audit.log
With this log spamming ;-) audit.log should show where things break. /var/log/zypp/history (the section with installing your updated AppArmor packages is enough) might also be helpful.
Crazy idea, since you already have your own branch packages: can you please add sha256sum /var/cache/apparmor/*/samba-bgqd >> /var/log/audit/audit.log sleep 5 in %post of apparmor-parser, apparmor-profiles and apparmor-abstractions before doing the above test? That sha256sum+sleep should be the last thing %post does.
(wild guess: both -profiles and -abstractions reload the profiles, and I wonder if that could be part of the problem. The first one triggers cache generation, and second one changes a file in /etc - with same timestamp as all packaged profiles, so that the cache doesn't get regenerated.)
-- You are receiving this mail because: You are on the CC list for the bug.