Comment # 15 on bug 1195463 from Christian Boltz

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

> 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/)

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.

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


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

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