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