AppArmor blocks Samba (smbd) chown in share

I’d like to use inherit own = yes in a share in /etc/samba/smb.conf.

The ownership of new files and directories is normally governed by effective uid of the connected user. This option allows the Samba administrator to specify that the ownership for new files and directories should be controlled by the ownership of the parent directory.

However, smbd cannot execute chown, which is due to AppArmor.

[2024/12/08 01:54:24.760169,  0] ../../source3/smbd/open.c:1017(change_file_owner_to_parent_fsp)
Dez 08 01:54:24 leapinst smbd[14386]:   change_file_owner_to_parent_fsp: failed to fchown file test/test-datei.txt to parent directory uid 1000. Error was Die Operation ist nicht erlaubt

To resolve it I have to run the following after each restart of smbd:

aa-disable /usr/sbin/smbd
aa-enforce /usr/sbin/smbd

I do not understand the background. But how to make this permanent?

See if this helps:
https://doc.opensuse.org/documentation/leap/archive/15.0/security/html/book.security/cha.apparmor.start.html#sec.apparmor.start.build

What does it mean? It works after boot? It stops to work after … what?

Your description is far too vague. Show the exact commands (full commands with complete output) which cause SAMBA stop working and make it working again.

If you insist on papering over instead of fixing the root cause - add these commands as ExecStartPost to smb.service.

After boot or after systemctl restart smb Samba cannot execute chown, as shown in the log line.

Basically, when I am user2 and upload a file into /home/user1 the expected behaviour is that the file owner will be user1. However, it stays user2 since AppArmor blocks smbd from changing ownership (see log).

I found out that it works, after I disable and re-enable the AppArmor-profile. Thus, I can tell it is related to AppArmor.

Thanks for your advise, which worked! That’s what I’ve done.

  1. cp /usr/lib/systemd/system/smb.service /etc/systemd/system/

  2. Add into section [service]

ExecStartPost=/usr/sbin/aa-disable /usr/sbin/smbd
ExecStartPost=/usr/sbin/aa-enforce /usr/sbin/smbd
  1. systemctl daemon-reload

However, I would be interested in fixing the root cause!!

Thanks but Samba is shipped with a fancy AppArmor profile already. I expect the mechanism in /etc/apparmor.d/local/usr.sbin.smbd-shares not working for chown (while chmod works , though).

What it actually does is disabling AppArmor confinement for smbd.

10:~ # systemctl restart smb.service
10:~ # ps -ef | grep smb
root      6767     1  1 19:18 ?        00:00:00 /usr/sbin/smbd --foreground --no-process-group
root      6771  6767  0 19:18 ?        00:00:00 /usr/sbin/smbd --foreground --no-process-group
root      6772  6767  0 19:18 ?        00:00:00 /usr/sbin/smbd --foreground --no-process-group
root      6774  6641  0 19:18 pts/2    00:00:00 grep --color=auto smb
10:~ # ll /proc/6767/attr
total 0
dr-xr-xr-x 2 root root 0 Dec  8 19:18 apparmor
-rw-rw-rw- 1 root root 0 Dec  8 19:18 current
-rw-rw-rw- 1 root root 0 Dec  8 19:18 exec
-rw-rw-rw- 1 root root 0 Dec  8 19:18 fscreate
-rw-rw-rw- 1 root root 0 Dec  8 19:18 keycreate
-r--r--r-- 1 root root 0 Dec  8 19:18 prev
-rw-rw-rw- 1 root root 0 Dec  8 19:18 sockcreate
10:~ # cat /proc/6767/attr/current 
smbd (enforce)
10:~ # aa-disable /usr/sbin/smbd
Disabling /usr/sbin/smbd.
10:~ # aa-enforce /usr/sbin/smbd
Setting /usr/sbin/smbd to enforce mode.
Warning: profile smbd represents multiple programs
10:~ # ll /proc/6767/attr
total 0
dr-xr-xr-x 2 root root 0 Dec  8 19:18 apparmor
-rw-rw-rw- 1 root root 0 Dec  8 19:18 current
-rw-rw-rw- 1 root root 0 Dec  8 19:18 exec
-rw-rw-rw- 1 root root 0 Dec  8 19:18 fscreate
-rw-rw-rw- 1 root root 0 Dec  8 19:18 keycreate
-r--r--r-- 1 root root 0 Dec  8 19:18 prev
-rw-rw-rw- 1 root root 0 Dec  8 19:18 sockcreate
10:~ # cat /proc/6767/attr/current 
unconfined
10:~ # 

So, it is possible that AppArmor profile is not compatible with your configuration and needs adjustment. Try aa-logprof, what does it suggest?

Are you telling me that AppArmor stops “protecting” when issuing aa-enable and aa-enforce? I wouldn’t have guessed that :-0

Consequently, I am interested in a real solution. Since I need it for longer, do you know by any chance if openSUSE 16 will still be based on Apparmor - or will it be SELinux?

Today it does not show anything but status information. Earlier, however, it offered to add “chown” to smb profile. I chose “add” to rule. But no prevail.

Reboot, trigger the error, provide the full output of

ausearch -ts boot -m AVC

It will be long, upload to https://paste.opensuse.org/

Hello, one simple question:
Does your Samba-User have the needed rights for the smb-Folder?

@Simonowski Yes, posix permissions are ok. Because it worked without AppArmor.

@arvidjaar There’s no output:

leapinst:~ # ausearch -ts boot -m AVC
<no matches>

Nonetheless, it works now. Do not ask me why. I even removed the systemd unit, using standard from /usr/lib/systemd now. Survived reboot.

leapinst:~ # cat /proc/2163/attr/current 
smbd (enforce)

This looks promising.

As it persists, I tried to find out where changes occured, see:

find /etc/apparmor.d/ -mtime -3
/etc/apparmor.d/usr.sbin.smbd
/etc/apparmor.d/local/usr.sbin.smbd

Maybe it was this command, which was triggered in the systemd unit: ExecStartPre=/usr/share/samba/update-apparmor-samba-profile?

More likely, it was aa-logprof.

Show the content of the both files.

/etc/apparmor.d/usr.sbin.smbd

# Last Modified: Sun Dec  8 01:27:16 2024
abi <abi/3.0>,

include <tunables/global>

profile smbd /usr/{bin,sbin}/smbd {
  include <abstractions/authentication>
  include <abstractions/base>
  include <abstractions/consoles>
  include <abstractions/cups-client>
  include <abstractions/nameservice>
  include <abstractions/openssl>
  include <abstractions/samba>
  include <abstractions/user-tmp>
  include <abstractions/wutmp>
  include if exists <local/usr.sbin.smbd-shares>
  include if exists <local/usr.sbin.smbd>
  include if exists <samba/smbd-shares>

  capability audit_write,
  capability chown,
  capability dac_override,
  capability dac_read_search,
  capability fowner,
  capability lease,
  capability net_bind_service,
  capability setgid,
  capability setuid,
  capability sys_admin,
  capability sys_resource,
  capability sys_tty_config,

  signal send set=term peer=samba-bgqd,

  /etc/mtab r,
  /etc/netgroup r,
  /etc/printcap r,
  /etc/samba/* rwk,
  /usr/etc/environment r,
  /usr/etc/security/limits.d/ r,
  /usr/etc/security/limits.d/*.conf r,
  /usr/lib*/samba/auth/*.so mr,
  /usr/lib*/samba/charset/*.so mr,
  /usr/lib*/samba/gensec/*.so mr,
  /usr/lib*/samba/pdb/*.so mr,
  /usr/lib*/samba/vfs/*.so mr,
  /usr/lib*/samba/{,samba/}samba-bgqd Px -> samba-bgqd,
  /usr/lib*/samba/{,samba/}samba-dcerpcd Px -> samba-dcerpcd,
  /usr/lib*/samba/{lowcase,upcase,valid}.dat r,
  /usr/lib/@{multiarch}/samba/**/ r,
  /usr/lib/@{multiarch}/samba/**/*.so{,.[0-9]*} mr,
  /usr/lib/@{multiarch}/samba/*.so{,.[0-9]*} mr,
  /usr/sbin/unix_chkpwd Px,
  /usr/share/samba/** r,
  /usr/{bin,sbin}/smbd mr,
  /usr/{bin,sbin}/smbldap-useradd Px,
  /var/cache/samba/** rwk,
  /var/lib/nscd/netgroup r,
  /var/lib/samba/** rwk,
  /var/lib/samba/usershares/{,**} rwlk,
  /var/lib/sss/pubconf/kdcinfo.* r,
  /var/spool/samba/** rw,
  /var/{cache,lib}/samba/printing/printers.tdb mrw,
  @{HOMEDIRS}/** rwlk,
  @{PROC}/@{pid}/mounts r,
  @{PROC}/sys/kernel/core_pattern r,
  @{run}/dbus/system_bus_socket rw,
  @{run}/samba/** rk,
  @{run}/samba/ncalrpc/ rw,
  @{run}/samba/ncalrpc/** rw,
  @{run}/{,samba/}smbd.pid rwk,
  owner /proc/@{pid}/loginuid r,

}

/etc/apparmor.d/local/usr.sbin.smbd

# Site-specific additions and overrides for 'usr.sbin.smbd'

/etc/apparmor.d/local/usr.sbin.smbd-shares

# autogenerated by update-apparmor-samba-profile 1.3 at samba start - do not edit!

"/home/"   rk,
"/home/**" rwkl,
"/var/tmp/"   rk,
"/var/tmp/**" rwkl,
"/var/lib/samba/drivers/"   rk,
"/var/lib/samba/drivers/**" rwkl,

It is not present in the default AppArmor profile. Consider opening openSUSE bug report (chose component AppArmor).

Let me explain, even if the main topic is already solved by adding capability chown,

aa-disable unloads the profile, and removes the protection/confinement from running processes, so effectively your smbd runs unconfined.

aa-enforce loads the profile again (and switches it to enforce mode) - but it can’t apply the protection/confinement to running processes (smbd stays unconfined). Only processes started after loading the profile will be protected/confined.

I’d recommend to use aa-complain instead of aa-disable.

It will switch the profile to complain (learning) mode, which allows everything and logs what would be denied. Then check your /var/log/audit/audit.log or use aa-logprof to update the profile. Finally, switch the profile back to enforce mode with aa-enforce.

Also, thanks for the bugreport at 1234327 – AppArmor profile for Samba (smbd) is missing chown capability

Many thanks for the explanation! Very appreciated. Will AppArmor make it into Leap 16?

Actually it is already in 16.0 :slight_smile: - Show openSUSE:Leap:16.0 / apparmor - openSUSE Build Service

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.