Bug 145222
Summary: | VFS full_audit filtering does not work reliably | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Petr Tuma <petr.tuma> |
Component: | samba | Assignee: | Simo Sorce <ssorce> |
Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | jmoore, mattdm, samba-bugs-list |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-10-22 13:37:06 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Petr Tuma
2005-01-15 16:26:02 UTC
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. |