samba - Feb 2021 - Samba and auditd

I'm using Samba to share a Linux directory X in a machine A with a Windows
Server OS installed in a machine B and it's working fine.

I have recently installed auditd in the Linux system (machine A) to track
tilesystem events initiated by users in both machines A and B. It works
fine for file read/writes done in machine A, but I don't see any events
initiated in machine B in auditd logs. Using strace to track syscalls
called by smbd processes, I see that the open() syscall is called by samba
to open files in X when files are read/written in the machine B, so I guess
smbd is just getting the file request sent by Windows Server, forwarding
them to the Linux kernel via syscalls and forwarding the syscalls responses
back to Windows Server.

Is there any difference between an open() syscall called by Samba or by a
local Linux process (e.g. the touch command) which could explain the
inconsistency in auditd behavior?

Thanks in advance.

On Thu, Feb 11, 2021 at 10:33:17PM -0300, Alan Evangelista via samba
wrote:
>I'm using Samba to share a Linux directory X in a machine A with a
Windows
>Server OS installed in a machine B and it's working fine.
>
>I have recently installed auditd in the Linux system (machine A) to track
>tilesystem events initiated by users in both machines A and B. It works
>fine for file read/writes done in machine A, but I don't see any events
>initiated in machine B in auditd logs. Using strace to track syscalls
>called by smbd processes, I see that the open() syscall is called by samba
>to open files in X when files are read/written in the machine B, so I guess
>smbd is just getting the file request sent by Windows Server, forwarding
>them to the Linux kernel via syscalls and forwarding the syscalls responses
>back to Windows Server.
Yes, that's exactly what we do.
>Is there any difference between an open() syscall called by Samba or by a
>local Linux process (e.g. the touch command) which could explain the
>inconsistency in auditd behavior?
No. Samba smbd *is* a local Linux process on machine A. There's
no reason its file access shouldn't be being logged by the
kernel of machine A.