From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 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 been omitted: Jan 9 04:21:39 gateway smbd_audit: nobody|brigada|stat|ok|Dokumenty Jan 10 07:31:42 gateway smbd_audit: nobody|192.168.0.162|opendir|ok|Kancelar/FAKTURY/2004/FO 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): 3.0.10-1 How reproducible: Always 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. Additional info: 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 list.
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 stopped. 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 myself.
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. Thank you!
FC3 is obsolete, now closing as WONTFIX, it should be working in later Fedora releases.