Update from 20220908 to 20221101 Breaks SMB
Today I updated from TW 20220908 to 20221101 and SMB no longer works I use SMB to access my linux server from both Windows and Linux guest network machines. This configuration has worked fine for years with no issues. Today after updating to TW 20221101 neither the Windows or Linux guests can access the network shares. Samba is running and on the Windows machine when I map to one of the shares it maps the drive but then when i try to access the mapped drive it gets Access Denied. There have been no configuration changes to the system for SMB in years It is not a permission issue on the drive because the user that maps to the SMB share on the Linux machine has full permissions rwx on Linux and Full Control on Linux. I believe the problem is related to apparmour changes for samba but I am unsure how to resolve the issue. Here are the messages that are appearing for the smb service. Nov 03 19:59:44 update-apparmor-samba-profile[9984]: + test No == Yes Nov 03 19:59:44 update-apparmor-samba-profile[9984]: + test -e /etc/apparmor.d/local/usr.sbin.smbd-shares Nov 03 19:59:44 update-apparmor-samba-profile[9984]: + grep -q 'update-apparmor-samba-profile 1.3' /etc/apparmor.d/local/usr.sbin.smbd-shares Nov 03 19:59:44 update-apparmor-samba-profile[9984]: + test /etc/samba/smb.conf -nt /etc/apparmor.d/local/usr.sbin.smbd-shares Nov 03 19:59:44 update-apparmor-samba-profile[9984]: + silentexit 'smb.conf is older than the AppArmor profile sniplet' Nov 03 19:59:44 update-apparmor-samba-profile[9984]: + exit 0 Nov 03 19:59:44 smbd[9988]: [2022/11/03 19:59:44.703896, 0] ../../source3/smbd/server.c:1741(main) Nov 03 19:59:44 smbd[9988]: smbd version 4.17.2-git.273.a55a83528b9SUSE-oS15.9-x86_64 started. Nov 03 19:59:44 smbd[9988]: Copyright Andrew Tridgell and the Samba Team 1992-2022 I suspect that the problem it is because it is complaining about smb.conf being different than what apparmour has but that config has not been changed since I originally set it up. Note that I first updated one of the client machines from TW 20220908 to 20221101 and after that machine was updated both the Windows machine and that TW 20221101 client had no problem accessing the TW 20220908 Linux server and SMB shares. Once the TW 20220908 server was updated to 22021101 then the linux clients and windows cllients could no longer access the TW 20221101 server. Is this a known issue? What are my options? I'd prefer to not have to rollback the machines but I also need a working SMB environment.
On 04.11.22 01:12, Joe Salmeri wrote:
What are my options? I'd prefer to not have to rollback the machines but I also need a working SMB environment.
Christian will hit me for the suggestion, but what about disabling apparmor on the SMB server for a test? "aa-teardown" should do the trick if I'm not mistaken. Or just "zypper rm apparmor && reboot" ;-) If this helps, then search this mailing list for Christian Boltz's excellent instructions on how to put apparmor into complain mode so that you can see what it is unhappy about. Good luck, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Hello, Am Freitag, 4. November 2022, 01:12:24 CET schrieb Joe Salmeri:
Today I updated from TW 20220908 to 20221101 and SMB no longer works [...] I believe the problem is related to apparmour changes for samba but I am unsure how to resolve the issue.
Check your /var/log/audit/audit.log for lines containing DENIED. If AppArmor really denies something, you'll have such lines. If you don't find any DENIED lines, the issue is most likely not related to AppArmor. If it turns out to be a problem with AppArmor, you can switch the affected profiles to complain mode (allow everything, but log what would be denied): aa-complain /etc/apparmor.d/usr.sbin.smbd (same for nmbd and winbindd) Note: In complain mode, log lines will have ALLOWED instead of DENIED. If your issue is really related to AppArmor, please open a bugreport and attach your audit.log. Oh, and don't even try Seife's idea to zypper rm apparmor - I can guarantee you that this won't work (Seife, try yourself if you don't believe me ;-) BTW: Samba also logs to /var/log/samba/ - maybe you can find some hints there.
Here are the messages that are appearing for the smb service. [...] Nov 03 19:59:44 update-apparmor-samba-profile[9984]: + silentexit 'smb.conf is older than the AppArmor profile sniplet' Nov 03 19:59:44 update-apparmor-samba-profile[9984]: + exit 0 [...] I suspect that the problem it is because it is complaining about smb.conf being different than what apparmour has but that config has not been changed since I originally set it up.
The messages you quoted just mean that the AppArmor profile sniplet is newer than your smb.conf, and that means there's no need to update it. Since the script is lazy, it just exits in this case. Regards, Christian Boltz -- A Perl program is correct if it gets the job done before your boss fires you. -- Larry Wall
Hi Christian, Thanks very much for your detailed response. While waiting for a response I tried to debug further. I know that after doing a zypper dup that an additional reeboot is also needed for the kernel purge / cleanup to run. To be safe (in case something else post update needed to run that I was not aware of ) I rebooted the server several times but the Linux and Windows clients still got the access denied when trying to access the shares. Windows machines could successfully map the drive ( so smbpasswd working fine ) but then could not access anything on the mapped drive. I also did a zypper verify which reported that everything was ok. Google searches of apparmor breaking SMB come up with a fair amount of hits with some on other distros and with some hits as recent as 08/2022 and 10/31/2022 This one talks about apparmor seems to break samba after every boot but they are running on Debian. As I test I tried the following: systemctl stop apparmor systemctl stop smb systemctl start apparmor systemctl start smb As soon as I did that shares and files started working and were accessible from Linux and Windows 10 clients. NOTHING was changed and my smb.conf from the 20220908 before zypper dup snapshot matches what is being used with the 20221101 updated snapshot. I have rebooted the server several times now after stopping and restarting apparmor and smb and everything continues to work now. That makes no sense to me because all of those reboots would have also stopped and started the services but they didn't work but when I manually did it things start working? Could this be a timing related issue when systemd starts apparmor and smbd that caused the issue since when I manually did it I wait for the other service to start before doing the second one? Looking at /var/log/audit/audit.log I do find lots of DENIED lines so seems clear that the issue was apparmor causing the access denied. Here are some examples: type=AVC msg=audit(1667529133.916:625): apparmor="DENIED" operation="file_receive" profile="smbd" name="/var/lib/nscd/netgroup" pid=15194 comm="smbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC msg=audit(1667529133.916:626): apparmor="DENIED" operation="open" profile="smbd" name="/vol/g/joe/bin/profile.ps1" pid=15194 comm="smbd" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 type=AVC msg=audit(1667529133.920:627): apparmor="DENIED" operation="open" profile="smbd" name="/vol/g/joe/bin/profile.ps1" pid=15194 comm="smbd" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 type=AVC msg=audit(1667529133.920:628): apparmor="DENIED" operation="open" profile="smbd" name="/vol/g/joe/bin/profile.ps1" pid=15194 comm="smbd" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 type=AVC msg=audit(1667529133.920:629): apparmor="DENIED" operation="open" profile="smbd" name="/vol/g/joe/bin/profile.ps1" pid=15194 comm="smbd" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 type=AVC msg=audit(1667529213.802:773): apparmor="DENIED" operation="file_receive" profile="smbd" name="/var/lib/nscd/netgroup" pid=15420 comm="smbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC msg=audit(1667529413.904:188): apparmor="DENIED" operation="file_receive" profile="smbd" name="/var/lib/nscd/netgroup" pid=2763 comm="smbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC msg=audit(1667529869.462:188): apparmor="DENIED" operation="file_receive" profile="smbd" name="/var/lib/nscd/netgroup" pid=3276 comm="smbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC msg=audit(1667530832.375:203): apparmor="DENIED" operation="file_receive" profile="smbd" name="/var/lib/nscd/netgroup" pid=4954 comm="smbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC msg=audit(1667530875.162:205): apparmor="DENIED" operation="file_receive" profile="smbd" name="/var/lib/nscd/netgroup" pid=4980 comm="smbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC msg=audit(1667531170.438:208): apparmor="DENIED" operation="file_receive" profile="smbd" name="/var/lib/nscd/netgroup" pid=3625 comm="smbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC msg=audit(1667589085.097:353): apparmor="DENIED" operation="file_receive" profile="smbd" name="/var/lib/nscd/netgroup" pid=2779 comm="smbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC msg=audit(1667589837.611:354): apparmor="DENIED" operation="file_receive" profile="smbd" name="/var/lib/nscd/netgroup" pid=4264 comm="smbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 I did NOT switch the profiles to complain mode because when I manually stopped and started apparmor and smbd then everything "magically" started to work. I have not submitted a bug report but will gladly do so if you want one but you have all the info from this message. I also looked at the samba logs too and the only messages since the zupper dup are [2022/11/03 18:34:40.283669, 0] ../../source3/smbd/server.c:1741(main) smbd version 4.17.2-git.273.a55a83528b9SUSE-oS15.9-x86_64 started. Copyright Andrew Tridgell and the Samba Team 1992-2022 WARNING: Unhandled message: interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, member=ActivatableServicesChanged WARNING: Unhandled message: interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, member=ActivatableServicesChanged WARNING: Unhandled message: interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, member=ActivatableServicesChanged WARNING: Unhandled message: interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, member=ActivatableServicesChanged WARNING: Unhandled message: interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, member=ActivatableServicesChanged WARNING: Unhandled message: interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, member=ActivatableServicesChanged WARNING: Unhandled message: interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, member=ActivatableServicesChanged but I also see that those messages have also occured back when the server was running 20220908. Let me know if you want/need any more info. On Fri, Nov 4, 2022 at 9:08 AM Christian Boltz <opensuse@cboltz.de> wrote:
Hello,
Am Freitag, 4. November 2022, 01:12:24 CET schrieb Joe Salmeri:
Today I updated from TW 20220908 to 20221101 and SMB no longer works [...] I believe the problem is related to apparmour changes for samba but I am unsure how to resolve the issue.
Check your /var/log/audit/audit.log for lines containing DENIED. If AppArmor really denies something, you'll have such lines.
If you don't find any DENIED lines, the issue is most likely not related to AppArmor.
If it turns out to be a problem with AppArmor, you can switch the affected profiles to complain mode (allow everything, but log what would be denied): aa-complain /etc/apparmor.d/usr.sbin.smbd (same for nmbd and winbindd)
Note: In complain mode, log lines will have ALLOWED instead of DENIED.
If your issue is really related to AppArmor, please open a bugreport and attach your audit.log.
Oh, and don't even try Seife's idea to zypper rm apparmor - I can guarantee you that this won't work (Seife, try yourself if you don't believe me ;-)
BTW: Samba also logs to /var/log/samba/ - maybe you can find some hints there.
Here are the messages that are appearing for the smb service. [...] Nov 03 19:59:44 update-apparmor-samba-profile[9984]: + silentexit 'smb.conf is older than the AppArmor profile sniplet' Nov 03 19:59:44 update-apparmor-samba-profile[9984]: + exit 0 [...] I suspect that the problem it is because it is complaining about smb.conf being different than what apparmour has but that config has not been changed since I originally set it up.
The messages you quoted just mean that the AppArmor profile sniplet is newer than your smb.conf, and that means there's no need to update it. Since the script is lazy, it just exits in this case.
Regards,
Christian Boltz -- A Perl program is correct if it gets the job done before your boss fires you. -- Larry Wall
Hello, Am Freitag, 4. November 2022, 20:43:17 CET schrieb Joe Salmeri:
To be safe (in case something else post update needed to run that I was not aware of ) I rebooted the server several times but the Linux and Windows clients still got the access denied when trying to access the shares. [...] As I test I tried the following:
systemctl stop apparmor systemctl stop smb
systemctl start apparmor systemctl start smb
For the records: systemctl stop does nothing (see systemctl cat apparmor for the explanation), therefore you basically did stop smb, start/reload apparmor (= reload all profiles) and then start smb. I wonder why this should give you a different behaviour than the reboots - even if...
As soon as I did that shares and files started working and were accessible from Linux and Windows 10 clients.
... reality shows that it did.
NOTHING was changed and my smb.conf from the 20220908 before zypper dup snapshot matches what is being used with the 20221101 updated snapshot.
Does smb.conf it still have the old timestamp, or a new one? (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.)
I have rebooted the server several times now after stopping and restarting apparmor and smb and everything continues to work now.
Wild guess: did your /etc/apparmor.d/local/usr.sbin.smbd-shares get updated when smb was (re)started? Please check the file timestamp to verify this.
That makes no sense to me because all of those reboots would have also stopped and started the services but they didn't work but when I manually did it things start working?
Indeed, that sounds interesting[tm].
Could this be a timing related issue when systemd starts apparmor and smbd that caused the issue since when I manually did it I wait for the other service to start before doing the second one?
Sounds unlikely IMHO.
Looking at /var/log/audit/audit.log I do find lots of DENIED lines so seems clear that the issue was apparmor causing the access denied.
Here are some examples:
Unless I overlooked something, the DENIED lines were for two files:
type=AVC msg=audit(1667529133.916:625): apparmor="DENIED" operation="file_receive" profile="smbd" name="/var/lib/nscd/netgroup" pid=15194 comm="smbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC
The profile already allows reading /etc/netgroup, therefore also allowing to read the nscd-cached variant makes sense. I'll make sure to get that allowed. That said - getting this denied is probably "just" an annoyance for smbd, but it shouldn't break accessing your shares. For that, we have (had?) the other log event:
msg=audit(1667529133.916:626): apparmor="DENIED" operation="open" profile="smbd" name="/vol/g/joe/bin/profile.ps1" pid=15194 comm="smbd" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 type=AVC
I guess that's a file on one of your samba shares? Now that things are working again, do you still get DENIED lines for this or another file on your shares?
I did NOT switch the profiles to complain mode because when I manually stopped and started apparmor and smbd then everything "magically" started to work.
As I said above, that's "just" a reload of all profiles - and so far, "magic" is the only explanation why this changed something, while reboots didn't.
I have not submitted a bug report but will gladly do so if you want one but you have all the info from this message.
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. Regards, Christian Boltz PS: sorry for the late answer - I clearly need longer days ;-) -- Aren't most of SUSE-employed community members part of the Research&Destroy department? [Sascha Peilicke in opensuse-project]
Hi Christian, Sorry for the delayed reply as I've been sick and recovering.
For the records: systemctl stop does nothing (see systemctl cat apparmor for the explanation), therefore you basically did stop smb, start/reload apparmor (= reload all profiles) and then start smb.
When I did the systemctl stop apparmor followed by a systemctl status apparmor it does show that the apparmor service is loaded but inactive hence the confusion. So maybe when the start/reload apparmor occurred that is what caused the issue to resolve itself?
Does smb.conf it still have the old timestamp, or a new one?
smb.conf DOES have a new timestamp because at one point I edited the file and saved it but I didn't make any changes and it still compares to the version from the snapshot before the update when the problems occurred. The before snapshot had a timestamp of 11/16/2021 which is the last time that I had to make a config change to smb.conf.
(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?
Wild guess: did your /etc/apparmor.d/local/usr.sbin.smbd-shares get updated when smb was (re)started? Please check the file timestamp to verify this.
You are correct that the /etc/apparmor.d/local/usr.sbin.smbd-shares file does have a newer timestamp which is about 2 min later than the saved ( but unchanged ) smb.conf file. So the timestamps on both files are newer BUT I just compared the current /etc/apparmor.d/local/usr.sbin.smbd-shares file to the one from the snapshot before the TW update and it too compares. So BOTH smb.conf and usr.sbin.smbd-shares from the before snapshot compare to their current versions and the only difference is that they now have newer timestamps. So I am back to my prior question....If BOTH files are exactly the same as they were before the TW update and the only difference is the newer timestamps on the current files then why did it stop working?
Unless I overlooked something, the DENIED lines were for two files:
The profile already allows reading /etc/netgroup, therefore also allowing to read the nscd-cached variant makes sense. I'll make sure to get
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 pid=26458 comm="samba-dcerpcdr requested_mask="r" denied_mask="r" fsuid=0 ouid=1000 type=AVC msg=audit(1662039375.496:2613): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F4465736B746F702F53686F7720746F2044656E6973652F pid=26458 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000 type=AVC msg=audit(1662415128.929:3390): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F50696374757265732F53616C6D6572692046616D696C792F pid=742 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000 type=AVC msg=audit(1662415128.929:3392): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F50696374757265732F53616C6D6572692046616D696C792F4B696D6265726C792F537572676572792030392D30352D323031322F pid=742 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000 type=AVC msg=audit(1662415128.929:3393): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F50696374757265732F53616C6D6572692046616D696C792F pid=742 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000 type=AVC msg=audit(1662415128.929:3394): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F50696374757265732F53616C6D6572692046616D696C792F4B696D6265726C792F537572676572792030392D30352D323031322F pid=742 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000 type=AVC msg=audit(1662415128.929:3395): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F50696374757265732F53616C6D6572692046616D696C792F4B696D6265726C792F537572676572792030392D30352D323031322F494D475F343335392E4A5047 pid=742 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000 type=AVC msg=audit(1662415128.929:3396): apparmor="DENIED" operation="file_inherit" profile="samba-dcerpcd" name=2F766F6C2F672F50696374757265732F53616C6D6572692046616D696C792F4B696D6265726C792F537572676572792030392D30352D323031322F494D475F343336302E4A5047 pid=742 comm="samba-dcerpcd" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000 Note that since I did the systemctl stop of apparmor ( which did nothing ) and stop of smb and then start for both everything has worked flawlessing and no access denied errors have occurred. So it seems the timestamp change for smb.conf caused the /etc/apparmor.d/local/usr.sbin.smbd-shares to be regenerated but as I said both files still compare to the files from the before TW snapshot so that doesn't explain why smb stopped working and was getting the denied errors after the TW update. that allowed. Thanks
That said - getting this denied is probably "just" an annoyance for smbd, but it shouldn't break accessing your shares. For that, we have (had?) the other log event:
msg=audit(1667529133.916:626): apparmor="DENIED" operation="open" profile="smbd" name="/vol/g/joe/bin/profile.ps1" pid=15194 comm="smbd" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 type=AVC I guess that's a file on one of your samba shares?
Yes, that is a reference to a file that is on one of the samba shares. See above for a breakdown of the 3 "groups" of files that were getting the access denied errors prior to restarting the servies.
Now that things are working again, do you still get DENIED lines for this or another file on your shares?
No, everything has worked flawlessly since the timestamp changed on smb.conf causing the reload.
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. 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?
PS: sorry for the late answer - I clearly need longer days ;-)
No worries, as I said I've been sick and recovering.
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]
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?
Yes, it started right after I rebooted as prior to do the update one of my other TW machines which had been updated to 20221101 was still connected to the server which was still running 20220908 ( but had just been updated but not rebooted yet)
(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 checked and you are correct. When I was running 20220908 I was using kernel 5.19.7-1.1 and after updating to 20221101 I was using kernel 6.0.5-1.1.
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.
Here are the results from my system # ls -l /usr/share/apparmor/cache/201d1af9.0/*smbd /var/cache/apparmor/*/*smbd -rw-r--r-- 1 root root 45K Oct 10 15:02 /usr/share/apparmor/cache/201d1af9.0/usr.sbin.smbd -rw------- 1 root root 45K Nov 3 22:41 /var/cache/apparmor/201d1af9.0/usr.sbin.smbd -rw------- 1 root root 42K Jul 22 2021 /var/cache/apparmor/2cfa59e0.0/usr.sbin.smbd -rw------- 1 root root 45K Oct 10 15:02 /var/cache/apparmor/3478577f.0/usr.sbin.smbd -rw------- 1 root root 43K Nov 16 2021 /var/cache/apparmor/b4df858c.0/usr.sbin.smbd
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".
Thanks for the info on aa-decode. I also found ausearch -i will convert the audit timestamps to human readable.
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?
No, it still has DENIED for /var/lib/nscd/netgroup. None for today 11/15/2022 but here are the ones for the last 3 days type=AVC msg=audit(11/12/22 14:40:33.855:2363) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=5876 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/12/22 15:45:40.592:2368) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=8010 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/12/22 16:02:46.111:2509) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=9657 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/12/22 16:09:05.773:2510) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=11716 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/12/22 16:10:02.687:2511) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=12305 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/12/22 16:17:35.934:2512) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=13866 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/12/22 16:18:21.973:2513) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=14018 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/12/22 16:37:19.127:2531) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=16458 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/12/22 16:40:38.650:2532) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=16626 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/12/22 16:44:11.904:2535) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=16840 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/12/22 16:47:22.615:2536) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=17500 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/13/22 10:51:01.809:2760) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=12575 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/13/22 11:18:16.630:2778) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=14627 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/13/22 14:56:43.959:2844) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=1606 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/14/22 10:09:35.969:3021) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=23281 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root type=AVC msg=audit(11/14/22 16:39:15.600:3090) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=14218 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root
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.
Ok, thanks, I've made a note of that.
Hello, Am Dienstag, 15. November 2022, 19:26:57 CET schrieb Joe Salmeri: [...]
Note that there is no /var/cache/apparmor/201d1af9.0/usr.sbin.smbd - my autogenerated profile sniplet is too old: [...] Here are the results from my system [...] -rw------- 1 root root 45K Nov 3 22:41 /var/cache/apparmor/201d1af9.0/usr.sbin.smbd
Just for explanation: That was created after you gave your smb.conf a new timestamp, which triggered an update of the profile sniplet.
Thanks for the info on aa-decode.
I also found ausearch -i will convert the audit timestamps to human readable.
Nice, I wasn't aware of that ;-) If you only want to convert a single timestamp, you can use date -d @1668549191
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?
No, it still has DENIED for /var/lib/nscd/netgroup.
None for today 11/15/2022 but here are the ones for the last 3 days
type=AVC msg=audit(11/12/22 14:40:33.855:2363) : apparmor=DENIED operation=file_receive profile=smbd name=/var/lib/nscd/netgroup pid=5876 comm=smbd requested_mask=r denied_mask=r fsuid=root ouid=root
Submitted upstream: https://gitlab.com/apparmor/apparmor/-/merge_requests/948 Regards, Christian Boltz -- liegt es vielleicht an den lauschigen 34°, die der Prozessor oder sowas nicht mitmacht? -> Soll ich mit dem Rechner jetzt zum Baggersee rausfah- ren und ihm ne Abkühlung verpassen... [Sebastian Schulze in suse-linux]
Hi Christian,
Nice, I wasn't aware of that ;-) If you only want to convert a single timestamp, you can use date -d @1668549191
Thanks. I was using the date method before I found ausearch -i
Submitted upstream: https://gitlab.com/apparmor/apparmor/-/merge_requests/948
Thanks very much. This entire situation got me thinking. Seems like there should be some sort of --force option with apparmor to have it force an update of the cache to avoid the problem in the future. Then that could be used whenever apparmor is updated in a new build. Does anything like that exist? Regards, Joe
Hello, Am Mittwoch, 16. November 2022, 18:24:06 CET schrieb Joe Salmeri:
Submitted upstream: https://gitlab.com/apparmor/apparmor/-/merge_requests/948
Thanks very much.
This entire situation got me thinking. Seems like there should be some sort of --force option with apparmor to have it force an update of the cache to avoid the problem in the future. Then that could be used whenever apparmor is updated in a new build.
Does anything like that exist?
apparmor_parser --skip-read-cache --write-cache -r /etc/apparmor.d/ should do that. ("Should" because I didn't test it - but the manpage explicitely recommends this combination.) An easier-to-remember way is to touch /etc/apparmor.d/$whatever which will also rebuild the cache for profiles including this file when the profiles get reloaded next time. That said - not shipping the precompiled cache is the easiest way to avoid problems like yours. I changed the package so that it doesn't include the precompiled cache for Tumbleweed anymore (SR was accepted yesterday, will be included in one of the next Tumbleweed snapshots). The only disadvantage is that booting after a major kernel update (with a new AppArmor feature hash) will need some additional seconds to build a new cache. (Updates of the apparmor-profiles or apparmor-abstractions package will also build a new cache, but that gets done after package installation.) For a more detailed (and summarized) description, see boo#1205659 Regards, Christian Boltz -- <suseROCKs> mrdocs, this is California. Define "normal" [from #opensuse-project]
apparmor_parser --skip-read-cache --write-cache -r /etc/apparmor.d/ should do that. ("Should" because I didn't test it - but the manpage explicitely recommends this combination.)
An easier-to-remember way is to touch /etc/apparmor.d/$whatever which will also rebuild the cache for profiles including this file when the profiles get reloaded next time.
Thanks for that info, I've made note of it.
That said - not shipping the precompiled cache is the easiest way to avoid problems like yours. I changed the package so that it doesn't include the precompiled cache for Tumbleweed anymore (SR was accepted yesterday, will be included in one of the next Tumbleweed snapshots). The only disadvantage is that booting after a major kernel update (with a new AppArmor feature hash) will need some additional seconds to build a new cache. (Updates of the apparmor-profiles or apparmor-abstractions package will also build a new cache, but that gets done after package installation.)
Excellent! I cannot imagine it takes that long to build the new cache.
For a more detailed (and summarized) description, see boo#1205659
Thanks for submitting that bug report. I just read it and see the long term solution which you mentioned is on the TODO list upstream. Personally I like your idea of not including them that way whenever a new kernel or apparmor profiles are updated they are rebuilt.
On 2022-11-15 22:56, Christian Boltz wrote:
Hello, Am Dienstag, 15. November 2022, 19:26:57 CET schrieb Joe Salmeri:
...
I also found ausearch -i will convert the audit timestamps to human readable.
Nice, I wasn't aware of that ;-)
Wow, what a find! Thanks, Joe. ... msg=audit(30/09/22 13:32:02.446:6930) .... Pity it doesn't print in ISO format. Tried: LC_TIME=en_DK.UTF-8 ausearch -i | less -S No effect. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Hi Carlos,
Wow, what a find! Thanks, Joe. .. msg=audit(30/09/22 13:32:02.446:6930) ... Pity it doesn't print in ISO format. Tried:
Glad it was useful. I noticed that your timestamps were coming out in dd/mm/yy format When I run it the come out in mm/dd/yyyy format. msg=audit(11/28/22 14:47:53.162:1143) I don't have LC_TIME set but LC_CTYPE is set to 'en_US.UTF-8'. I tried setting LC-CTYPE to your value but my results still came out the same as above. Since you are getting a different format than I am though it leads me to believe that there must be some other setting which it is using which would get your desired result I just don't know what it is. FYI, -i also converts uuid to account names.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2022-11-28 at 15:03 -0500, Joe Salmeri wrote:
Hi Carlos,
Wow, what a find! Thanks, Joe. .. msg=audit(30/09/22 13:32:02.446:6930) ...>> Pity it doesn't print in ISO format. Tried:
Glad it was useful.
I noticed that your timestamps were coming out in dd/mm/yy format
When I run it the come out in mm/dd/yyyy format.
msg=audit(11/28/22 14:47:53.162:1143)
I don't have LC_TIME set but LC_CTYPE is set to 'en_US.UTF-8'. I tried setting LC-CTYPE to your value but my results still came out the same as above.
No change here: Telcontar:~ # LC_TIME=es_ES.UTF-8 LC_CTYPE=es_ES.UTF-8 ausearch -i | head -2 - ---- type=USER_START msg=audit(30/09/22 13:32:02.446:6930) : pid=30401 uid=root auid=news ses=796 subj==unconfined msg='op=PAM:session_open grantors=pam_loginuid,pam_systemd,pam_limits,pam_unix,pam_umask,pam_gnome_keyring acct=news exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success' Telcontar:~ # LC_TIME=es_ES.UTF-8 LC_CTYPE=es_ES.UTF-8 ausearch -i | head -2 - ---- type=USER_START msg=audit(30/09/22 13:32:02.446:6930) : pid=30401 uid=root auid=news ses=796 subj==unconfined msg='op=PAM:session_open grantors=pam_loginuid,pam_systemd,pam_limits,pam_unix,pam_umask,pam_gnome_keyring acct=news exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success' Telcontar:~ # Telcontar:~ # LC_TIME=es_ES.UTF-8 LC_CTYPE=en_DK.UTF-8 ausearch -i | head -2 - ---- type=USER_START msg=audit(30/09/22 13:32:02.446:6930) : pid=30401 uid=root auid=news ses=796 subj==unconfined msg='op=PAM:session_open grantors=pam_loginuid,pam_systemd,pam_limits,pam_unix,pam_umask,pam_gnome_keyring acct=news exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success' Telcontar:~ # Where does it take the date format from? Ah, GOT IT! Telcontar:~ # LC_TIME=en_DK.UTF-8 LC_CTYPE=en_DK.UTF-8 ausearch -i | head -2 - ---- type=USER_START msg=audit(2022-09-30 13:32:02.446:6930) : pid=30401 uid=root auid=news ses=796 subj==unconfined msg='op=PAM:session_open grantors=pam_loginuid,pam_systemd,pam_limits,pam_unix,pam_umask,pam_gnome_keyring acct=news exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success' Telcontar:~ # and: Telcontar:~ # LC_TIME=en_DK.UTF-8 ausearch -i | head -2 - ---- type=USER_START msg=audit(2022-09-30 13:32:02.446:6930) : pid=30401 uid=root auid=news ses=796 subj==unconfined msg='op=PAM:session_open grantors=pam_loginuid,pam_systemd,pam_limits,pam_unix,pam_umask,pam_gnome_keyring acct=news exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success' Telcontar:~ # The other day it did not work, perhaps I did some foo.
Since you are getting a different format than I am though it leads me to believe that there must be some other setting which it is using which would get your desired result I just don't know what it is.
FYI, -i also converts uuid to account names.
AH :-) - -- Cheers, Carlos E. R. (from openSUSE 15.3 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCY4UXIRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVkdYAmgLgS2X7BW06NautX6f4 29hoi6QLAJ4oAR+B1YLevIAl3o7kIH8H6k4GfQ== =8b8g -----END PGP SIGNATURE-----
On 2022-11-04 14:08, Christian Boltz wrote:
Hello,
Am Freitag, 4. November 2022, 01:12:24 CET schrieb Joe Salmeri:
Today I updated from TW 20220908 to 20221101 and SMB no longer works [...] I believe the problem is related to apparmour changes for samba but I am unsure how to resolve the issue.
Check your /var/log/audit/audit.log for lines containing DENIED. If AppArmor really denies something, you'll have such lines.
Unrelated, but this post reminded me that I had an issue with samba and AA in Leap 15.3, which I have been ignoring, till today; aa-logprof just added these lines: --- /etc/apparmor.d/usr.sbin.smbd 2022-04-15 20:39:33.840172862 +0200 +++ /tmp/tmpyx87k_w0 2022-11-05 18:54:20.666807500 +0100 @@ -1,4 +1,4 @@ -# Last Modified: Fri Apr 15 20:39:33 2022 +# Last Modified: Sat Nov 5 18:54:20 2022 #include <tunables/global> profile smbd /usr/{bin,sbin}/smbd { @@ -58,5 +58,7 @@ profile smbd /usr/{bin,sbin}/smbd { @{HOMEDIRS}/** rwlk, @{PROC}/@{pid}/mounts r, @{PROC}/sys/kernel/core_pattern r, + owner /proc/*/fd/ r, + owner /{,var/}run/samba/** rwk, } Just saying in case it helps. The errors were: Profile: smbd Path: /proc/2524/fd/ New Mode: owner r Severity: 6 [1 - owner /proc/*/fd/ r,] 2 - owner /proc/2524/fd/ r, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish Profile: smbd Path: /run/samba/samba-bgqd.pid Old Mode: rk New Mode: owner rwk Severity: unknown [1 - owner /{,var/}run/samba/** rwk,] 2 - owner /run/samba/samba-bgqd.pid rwk, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish Adding owner /{,var/}run/samba/** rwk, to profile. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Hello, Am Samstag, 5. November 2022, 19:00:03 CET schrieb Carlos E. R.:
Unrelated, but this post reminded me that I had an issue with samba and AA in Leap 15.3, which I have been ignoring, till today; aa-logprof just added these lines:
--- /etc/apparmor.d/usr.sbin.smbd 2022-04-15 20:39:33.840172862
+ owner /proc/*/fd/ r, + owner /{,var/}run/samba/** rwk,
Your second rule looks a bit broad, but let's see...
The errors were:
Profile: smbd Path: /proc/2524/fd/ New Mode: owner r Severity: 6
[1 - owner /proc/*/fd/ r,] 2 - owner /proc/2524/fd/ r, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish
That looks sane.
Profile: smbd Path: /run/samba/samba-bgqd.pid Old Mode: rk New Mode: owner rwk Severity: unknown
[1 - owner /{,var/}run/samba/** rwk,] 2 - owner /run/samba/samba-bgqd.pid rwk, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish Adding owner /{,var/}run/samba/** rwk, to profile.
Picking the second option here would have been better / more secure. That said - I'm surprised why smbd wants to write the pid file of samba-bgqd. @Noel: does this sound correct to you? (I know that smbd starts samba-bgqd, but I'd expect - without looking at any source code - that samba-bgqd writes its pid file.) Carlos, if you still have the audit.log for these two events, please send it to me off-list. Regards, Christian Boltz -- What does that mean. Am I guilty? Of course, but what am I accused for? ;-) [Hans-Peter Jansen in opensuse-factory]
participants (4)
-
Carlos E. R. -
Christian Boltz -
Joe Salmeri -
Stefan Seyfried