An event reporting framework for Samba

Richard Sharpe realrichardsharpe at
Sun Jan 24 17:40:51 UTC 2016

On Sun, Jan 24, 2016 at 7:06 AM, Stefan Metzmacher <metze at> wrote:
> Hi Richard,
>> I am seeking feedback on an idea for an improvement in Samba.
>> In modern storage environments people want analytics and Samba needs
>> to be able to provide the information requested.
>> .rts from those events.
>> In general, they would like a stream of events that they will then
>> store in a database and from which they can generate interesting
>> reports.
>> For example, they would like:
>> 1. Info about every logon, including who, when, where.
>> 2. Info about every logoff, same as above.
>> 3. Info about every tree connect, when, what, who.
>> 4. Info about every tree disconnect, when, what, who.
>> 5. Info about every file create
>> 6. Info about every file delete, rename, change of attributes, and so on.
>> From these they can generate reports about who accesses what and how
>> many files are created, etc.
>> Now, some of this could be achieved today by adding event reporting
>> calls within a VFS module, not all of it can without modifying Samba.
>> Moreover, I have probably not thought of everything that people might
>> want events for. It might be easier if we had an event reporting
>> framework that users could plug into. The default behavior would be to
>> do absolutely nothing, especially if the user has not provided the
>> module.
>> Does this sound like a useful thing to do?
> Yes, I think we should try to base this on the SACLs of security descriptors
> as much as possible. This would solve the problem for everything that
> is protected by a security descriptor not just files.
> I'm wondering why you added SMB_VFS_AUDIT_FILE() with
> and never add any use to it. Should we remove that again as it's
> completely unused?

It was added as a way to have NTFS-style auditing, but then I never
found a use for it, since most people don't use that, it seems.

They would rather use stuff like Varonis and etc (there's at least one
more of them around.)

As to whether it needs to be removed, I don't know. Maybe someone did
their own file-level auditing.

Richard Sharpe

More information about the samba-technical mailing list