From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
When using the full_audit VFS, with configuration as follows:
vfs objects = full_audit
full_audit:prefix = %u|%m
full_audit:success = connect opendir chdir mkdir rmdir open unlink rename
full_audit:failure = connect opendir chdir mkdir rmdir open unlink rename
The log will also contain readdir and stat entries, which should have
Jan 9 04:21:39 gateway smbd_audit: nobody|brigada|stat|ok|Dokumenty
Jan 10 07:31:42 gateway smbd_audit:
Jan 10 07:31:42 gateway smbd_audit: nobody|192.168.0.162|readdir|ok|
Jan 10 07:31:42 gateway last message repeated 920 times
Jan 10 07:31:42 gateway smbd_audit: nobody|192.168.0.162|closedir|ok|
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Use VFS full_audit with the config above and try to e.g. search for a
file from Windows SMB client.
Actual Results: Log entries that should have been masked are visible.
Expected Results: There should be no readdir (and other) entries
unless explicitly listed in the config.
The bad thing is that the lack of filtering makes full_audit unusable,
it generates too many entries and significantly slows down the server.
Found exactly the same problem with greatly-reduced list of actions for success
Actually, on further testing, I was able to get full_audit to work as
expected. We had a server with several shares using full_audit with the
following vfs operations in the audit lists:
full_audit:success = connect mkdir rmdir opendir open rename unlink chown set_nt_acl
full_audit:failure = connect chdir mkdir rmdir opendir open rename chown set_nt_acl
I tried paring this list down on one share to a bare minimum. After paring it
down, I would reload or restart the daemon. For some reason, I would continue
to see 'stat' and 'readdir' log entries from some clients (but not all).
Finally, I removed the full_audit entries from all shares and reloaded the
daemon. Audit logs quickly stopped altogether. Then I put back the operations
to one share, one or two operations at a time and reloaded the daemon after
each. Audit logging began to reappear, but only for the operations specified in
the lists. By the time I was satisfied, I had the following operations lists:
full_audit:success = mkdir rmdir open rename unlink chown set_nt_acl
full_audit:failure = opendir chdir mkdir rmdir open rename chown set_nt_acl
I then restored these lists to all the shares I inteneded to audit. With
these in place, I saw no more 'readdir' or 'stat' log entries for any user for
at least an hour. A that point, I could no longer continue monitoring the
situation. Frankly, I don't know what was really going on. I will report back
if the unexpected behavior occurs again.
I was able to do some monitoring today, and the problem is back. I found
that full_audit would log everything, regardless of what the operations lists
said, provided you use a tool such as Nautilus or Windows Explorer to navigate
the share. Otherwise, it acted as expected. For example, I mounted one of the
audited shares on my Linux box using the mount.cifs tool provided with Samba. I
then cruised through the filesystem, opened files, ran 'stat' on them, tried
changing ownership and permissions, and the only audit logs generated were those
conforming to the operations lists in my last post. I also opened the mounted
directory in Nautilus. After a few minutes, I suddenly noticed a large number
of 'readdir', 'closedir', 'stat', and 'lstat' logs generated for my username. I
tried killing Nautilus to no avail. When I unmounted the share, the logging
I then connected to the same share using smbclient and tried multiple file
and directory operations, including 'ls', 'mkdir', 'rmdir', 'cd', 'rename',
'stat', 'chown', 'chmod', 'get' and 'put'. Full_audit only logged operations
appearing in the lists. Other users who were using Windows Explorer to navigate
the same share would generate large numbers of 'readdir' and 'stat' entries. It
appears to me that something done by these GUIs is triggering a bug in the
module. I don't have the time or expertise right now to run a debugger on this
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Verified the presence of this bug in samba 3.0.10 from Fedora Core 3.
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
FC3 is obsolete, now closing as WONTFIX, it should be working in later Fedora