You are not logged in.
Recently I posted a previous topic regarding apparmor and samba
https://bbs.archlinux.org/viewtopic.php?id=276044
A bug ticket was raised
https://bugs.archlinux.org/task/74614
and both the ticket and forum post were marked solved. However, I still cannot see my public shares.
Using
# grep -i denied /var/log/audit/audit.logI see the following still:
type=AVC msg=audit(1668827961.356:772): apparmor="DENIED" operation="open" profile="samba-dcerpcd" name="/var/cache/samba/names.tdb" pid=393392 comm="samba-dcerpcd" requested_mask="wrc" denied_mask="wrc" fsuid=0 ouid=0FSUID="root" OUID="root"
If I temporarily disable the profile
apparmor_parser -R /etc/apparmor.d/samba-dcerpcdalong with samba-rpcd-classic and samba-rpcd I can then see my shares.
I can't find anything in the Arch wiki about modifying those files, only
https://wiki.archlinux.org/title/Samba# … n_AppArmor
Is this a sign that the bug is not actually fixed or something new?
Last edited by farmerdave (2023-04-18 23:01:41)
Offline
I'm guessing it's new. I'm seeing the same thing after installing apparmor.
Offline
Well, you can interactively add the necessary rules by executing
sudo aa-logprof Offline
@farmerdave I am getting this exact same issue. Did you ever figure out the proper way around this?
Offline
Seems like adding the line:
/var/cache/samba/** rwk,to the samba-dcerpcd, samba-rpcd, and samba-rpcd-classic files in /etc/apparmor.d/local works around the above issue.
In addition, samba-dcerpcd also needs:
@{run}/samba-dcerpcd.pid wk,The exceptions for the file shares themselves need to be added to both samba-rpcd-classic and usr.sbin.smbd, contrary to what the Archwiki says.
Can anyone chime in on whether these changes are correct or is there a much better way? Is this technically a bug in the apparmor profiles? Just seems like a lot to change just to get Samba working with AppArmor...
Last edited by UrbenLegend (2023-01-02 22:18:54)
Offline
This issue should be fixed in apparmor 3.1.3-1 which has the updated samba profiles.
Offline
@nl6720 The new apparmor update mostly works, but I still needed to add the following to /etc/apparmor.d/local/samba-rpcd-classic
include if exists <local/usr.sbin.smbd-shares>to get my Samba shares working. Considering that /etc/apparmor.d/usr.sbin.smbd includes this rule by default, shouldn't /etc/apparmor.d/samba-rpcd-classic also include this rule as well?
I think many users will get confused when they try to add an apparmor exception for a new Samba share using usr.sbin.smbd-shares, only to realize that it doesn't really work because samba-rpcd-classic doesn't include it. It would be nice if that file was a "one-stop shop" for adding share exceptions.
Offline
I just define my shares in /etc/apparmor.d/local/usr.sbin.smbd and it works for me™.
Last edited by nl6720 (2023-03-02 12:04:18)
Offline
That's perplexing to me considering that the default /etc/apparmor.d/usr.sbin.smbd includes both <local/usr.sbin.smbd> and <local/usr.sbin.smbd-shares>:
# Permissions for all configured shares (file autogenerated by
# update-apparmor-samba-profile on service startup on Debian and openSUSE)
include if exists <samba/smbd-shares>
include if exists <local/usr.sbin.smbd-shares>
# Site-specific additions and overrides. See local/README for details.
include if exists <local/usr.sbin.smbd>So it shouldn't really matter which file I put the override in right?
Could I trouble you for a quick test? I am wondering if your share still works if you place the overrides in <local/usr.sbin.smbd-shares> instead. I am trying to figure out if its because I am sharing from an external drive or something like that.
Offline
/etc/apparmor.d/local/usr.sbin.smbd-shares works fine too. Though, since it is supposed to be an automagically generated file on certain distros, I prefer using /etc/apparmor.d/local/usr.sbin.smbd instead.
Offline
Okay, I did a bit more digging into this. If I don't add in the additional rules into /etc/apparmor.d/local/samba-rpcd-classic, I can still access the share if I manually type in the path and navigate to the share directly.
So for example, let's say I have a share called TestShare. I can type in smb://<hostname>/TestShare into my file manager and I can view the files within the share. However, if I simply type in smb://<hostname>, I don't see a TestShare folder and so I can't double-click on it to enter the share.
Adding the additional rule into samba-rpcd-classic allows the share to properly appear as a clickable folder.
In my system logs, I see these denials without the rule:
kernel: audit: type=1400 audit(1678843972.796:735): apparmor="DENIED" operation="open" class="file" profile="samba-rpcd-classic" name=2F72756E2F6D656469612F62656E7869616F2F4D792050617373706F72742F4D6973632F444C2F pid=16950 comm="rpcd_classic" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000Perhaps this requires an additional patch to the default apparmor rules to allow these shares to properly appear? Are you navigating directly to the share or can you actually see the share as a folder in the Samba root?
Offline
IIRC the situation with share browsing is complicated.
Using Dolphin I can browse shares on a host with an (intentionally) insecure /etc/samba/smb.conf:
server min protocol = LANMAN1
ntlm auth = yes
lanman auth = yesBesides AppArmor, it could be a configuration issue in /etc/samba/smb.conf or a firewall issue.
Offline
Would it really be an smb or firewall issue if browsing works correctly without Apparmor? I think if its a firewall issue, it definitely would not have worked with or without Apparmor. There may very well be some SMB config that makes it more compatible with Apparmor, but I am unaware of what that may be. Hmm, should I report this upstream? Wondering whether its more appropriate to report to Samba or Apparmor.
Offline
/etc/apparmor.d/local/usr.sbin.smbd-shares works fine too. Though, since it is supposed to be an automagically generated file on certain distros, I prefer using /etc/apparmor.d/local/usr.sbin.smbd instead.
I can confirm with current updates and adding specific shares to /etc/apparmor.d/local/usr.sbin.smbd I can access shares from linux and windows clients.
Offline