Samba vfs_full_audit reports everything

[Paul Rensing]

We have Samba file sharing set up to log a number of operations using the VFS full audit capability. This is in hopes of stopping ransomware. See for example https://github.com/roblio/ransom2ban.

The configuration in smb.conf contains this:
   # Anti-ransomware full audit to /var/log/ransom2ban/samba_audit.log
   full_audit:failure = none
   full_audit:success = pwrite pwrite_send pwrite_recv write rename unlink mkdir
   full_audit:prefix = IP=%I|USER=%u|SHARE=%S
   full_audit:facility = local5
   full_audit:priority = debug
   vfs objects = full_audit

Before the update to 4.13.14+dfsg-0ubuntu0.20.04.1, this worked fine. With the update, the logging has gone through the roof, and appears to be logging *all* operations, independent of the settings. For instance, it logs "listxattr" despite it being not listed. I also tried adding "!listxattr" to the "success" list, but no change.

Note that our CentOS machine just got 4.13 as well, and does not have this problem.

Maybe this is a testing parameter that was accidentally left in the build??

----------------
# lsb_release -rd
Description: Ubuntu 20.04.3 LTS
Release: 20.04

# dpkg-query -W samba\*
samba 2:4.13.14+dfsg-0ubuntu0.20.04.1
samba-common 2:4.13.14+dfsg-0ubuntu0.20.04.1
samba-common-bin 2:4.13.14+dfsg-0ubuntu0.20.04.1
samba-dsdb-modules:amd64 2:4.13.14+dfsg-0ubuntu0.20.04.1
samba-libs:amd64 2:4.13.14+dfsg-0ubuntu0.20.04.1
samba-testsuite
samba-vfs-modules:amd64 2:4.13.14+dfsg-0ubuntu0.20.04.1

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Bjoern Voigt (bjoern)]

Please check your log files. You may have this line:

smbd_audit[.....]: Could not find opname rename, logging all

This means, that Samba is logging everything, because "rename" opname is not found. You have to use different names:

rename -> renameat
unlink -> unlinkat

After that, logging works fine

[Paul Rensing (prensing)]

Thanks. Yes that was it. The "could not find opname" messages were buried in the machine-specific logs (not the main "smbd.log" file), and I did not think to look for them.

I did check and the CentOS machine had the newer "unlinkat" type names, so that is why it did not start failing.

Thanks for the assistance and sorry to bother you.