Comment # 16 on bug 1195463 from
(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: