Hello, Am Freitag, 11. November 2022, 20:39:00 CET schrieb Joe Salmeri:
Sorry for the delayed reply as I've been sick and recovering.
No worries, and get welll again soon!
So maybe when the start/reload apparmor occurred that is what caused the issue to resolve itself?
In this specific case, I'd guess that restarting samba (which, thanks to the new timestamp on smb.conf, updated and reloaded the profile) resolved the issue.
(A newer timestamp means /usr/share/samba/update-apparmor-samba-profile will update /etc/apparmor.d/local/usr.sbin.smbd-shares and reload the profile when you (re)start smb.)
So it would appear that because once I saved the file with a newer timestamp that triggered the reload as you described, however, the file didn't really change which begs the question as to why didn't it work after the TW update or should the TW update have forced a reload of the profile and didn't which caused the issue?
My guess is that you might have hit a problem with an outdated cache file in /var/cache/apparmor/ (the cache is only checked based on the timestamps of the involved files in /etc/apparmor.d/). However, I'm still a bit surprised because the profiles should have a new-enough timestamp (there have been some AppArmor changes unrelated to the profiles, but as part of that, the profiles get a newer timestamp when the package gets built.) Another possible part of the puzzle is the precompiled cache in /usr/share/apparmor/cache/ - maybe your autogenerated samba profile sniplet was "too old" so that the precompiled cache "won"? But again, there were no recent changes to the profiles, so in this case it {w,sh}ould have been broken for you since quite a while. Hmm, maybe I have an explanation. It sounds like a combination of corner case and bad luck, but it's still more likely than the guesses above: Did the breakage start with the reboot after a kernel update? (Since you came from 20220908, it's likely that you had kernel 5.19.x before, and now have 6.0.x. If in doubt, check /var/log/zypp/history for the date of kernel updates.) I see that a recent kernel update (probably 6.0.x, installed around 2022-10-07) got a new cache hash (which means it has support for new AppArmor features), which also means a fresh cache file in /var/cache/apparmor/$hash/ will be created. But - only if a profile or include file is newer than the precompiled cache. With your timestamp from last year, that would not have been the case, and the precompiled cache might have been used. I already wanted to ask for a backup of /var/cache/apparmor/ in the broken state, but then checked on my own system (I have samba installed, but only start/use it every few months.) # ls -l /usr/share/apparmor/cache/201d1af9.0/*smbd \ /var/cache/apparmor/*/*smbd [...] 4. Nov 18:23 /usr/share/apparmor/cache/201d1af9.0/usr.sbin.smbd [...] 7. Okt 21:40 /var/cache/apparmor/3478577f.0/usr.sbin.smbd Note that there is no /var/cache/apparmor/201d1af9.0/usr.sbin.smbd - my autogenerated profile sniplet is too old: [...] 13. Apr 2022 /etc/apparmor.d/local/usr.sbin.smbd-shares and therefore /usr/share/apparmor/cache/201d1af9.0/usr.sbin.smbd is newer and looks "valid enough" :-/ OK, so we have an explanation. I guess that's one more reason to remind upstream to move "use a checksum of the /etc/apparmor.d/ files when validating the cache" more to the top of the TODO list. [...]
Unless I overlooked something, the DENIED lines were for two files: I did not give you all the denied lines but that had access denied.
Looking at the log I can break the denied lines into 3 groups
1) /var/lib/nscd/netgroup 2) files on smb shares which I have setup 3) lines which are for samba-dcerpcd
Here are some examples of the samba-dcerpcd log lines:
type=AVC msg=audit(1662039375.496:2612): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F4465736B746F702F53686F7720746F2044656E6973652F
In case you wonder - that cryptic name= can be decoded with aa-decode. In this case, it's a directory starting with /vol/g/ and including a space (which is the reason why it was encoded) - so it sums up with "file on the shares".
If the only new log events you still get are for /var/lib/nscd/netgroup, a mail reply is enough. If you get more/different log lines, please open a bugreport and attach your audit.log.
Correct no denied errors since I restart the services.
Does that mean you also don't get denials for /var/lib/nscd/netgroup ? If not, maybe it was related to the strange things you've seen, and we don't need to allow it?
So do we have an explanation as to what occurred? Seems odd that the files compare and that the only change is that the smb.conf got a new timestamp causing apparmor to reload the both files still compared to before the update.
So I guess if it happened again, I would just touch smb.conf causing apparmor to reload and then it would work again?
Right. And before doing that, please save /etc/apparmor.d/, /usr/share/apparmor/cache/ and/var/cache/apparmor/ as a tar.gz so that we can easily check for differences and timestamps. Regards, Christian Boltz PS: non-random signature -- There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. [http://martinfowler.com/bliki/TwoHardThings.html]