Bugzilla – Bug 945563
Samba 4.3.0 does not work because of AppArmor
Last modified: 2015-09-20 12:45:21 UTC
Created attachment 647048 [details] audit.log Tumbleweed Snapshot 20150909 introduced Samba 3.4.0. After this update, Samba services nmbd and smbd do not start anymore because of now inadequate AppArmor permissions. The following commands temporarily fix the issue: > aa-complain /etc/apparmor.d/usr.sbin.smbd > aa-complain /etc/apparmor.d/usr.sbin.nmbd > systemctl resatart smbd.service > systemctl resatart nmbd.service In attachment you can find the audit.log file collected after enabling the aa-complain.
Thanks for the report! Both profiles - /etc/apparmor.d/usr.sbin.{n,s}mbd - aren't part of the Samba package. They are shipped as part of the apparmor-profiles package. Therefore I'm passing this issue to Christian.
Please edit /etc/apparmor.d/usr.sbin.smbd and /etc/apparmor.d/usr.sbin.nmbd and add the following lines to both of them (inside the { ...} section): /etc/samba/sock/ rw, /etc/samba/sock/* w, That should cover all samba-related events in your audit.log. Lars, does winbindd also need those permissions? (I wonder if I should add them to abstractions/samba instead of the individual profiles.)
(In reply to Christian Boltz from comment #2) > Lars, does winbindd also need those permissions? (I wonder if I should add > them to abstractions/samba instead of the individual profiles.) winbindd suffers from the same issue. As suggested in comment#2 I tested the abstractions/samba approach and the three three services are working while all failed before.
OK, so the final patch (which I just submitted upstream) is: === modified file 'profiles/apparmor.d/abstractions/samba' --- profiles/apparmor.d/abstractions/samba 2015-05-18 23:25:26 +0000 +++ profiles/apparmor.d/abstractions/samba 2015-09-13 07:44:19 +0000 @@ -10,6 +10,8 @@ # ------------------------------------------------------------------ /etc/samba/* r, + /etc/samba/sock/ rw, + /etc/samba/sock/* w, /usr/share/samba/*.dat r, /usr/share/samba/codepages/{lowcase,upcase,valid}.dat r, /var/cache/samba/ w, Giuseppe: I forgot to mention that you need to run "rcapparmor reload" after manually editing a profile.
I was late reading your first comment and applied directly the second fix to abstractions/samba. I confirm it works fine. Thank you for your prompt support!
You are welcome ;-) I just commited an updated package to Factory (SR 330818).
This is an autogenerated message for OBS integration: This bug (945563) was mentioned in https://build.opensuse.org/request/show/330818 Factory / apparmor
This is an autogenerated message for OBS integration: This bug (945563) was mentioned in https://build.opensuse.org/request/show/330873 Factory / apparmor
For the records - this bugreport is about Samba 4.3, not 3.4 ;-) Also, as discussed on the AppArmor mailinglist, /etc/ is not really a good place for sockets. Therefore reopening and assigning back to Lars ;-) (Please don't wait too long with getting a better path (/run/samba/ ?) - I'd hate to keep /etc/samba/sock/ in the profile, but removing it again is only a sane option if the paths are changed quickly ;-)
I'm sorry, but /etc/samba/sock/ has to be replaced by /var/lib/samba/private/sock We found a quite old packaging bug in the SUSE Samba package which has its roots ten years back. On the SUSE Samba side this got fixed with build source timestamp 3481 which is on the way to openSUSE Factory with submit request 331521 https://build.opensuse.org/request/show/331521
Thanks for reopening and please (re)adjust the AppArmor package.
(In reply to Lars Müller from comment #10) > I'm sorry, but /etc/samba/sock/ has to be replaced by > > /var/lib/samba/private/sock abstractions/samba already contains /var/lib/samba/** rwk, so the only thing I need to do is to drop the patch that adds /etc/samba/sock/ ;-) Since the patch didn't enter Factory yet (the SR was still pending), I just removed all traces of it (including the .changes entry) and sent a new SR. > We found a quite old packaging bug in the SUSE Samba package which has > its roots ten years back. - --with-privatedir=%{CONFIGDIR} Oh, nice ;-)
.
https://lists.ubuntu.com/archives/apparmor/2015-September/008558.html points to the thread at the AppArmor list.