Bug 145222 - VFS full_audit filtering does not work reliably
VFS full_audit filtering does not work reliably
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: samba (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Simo Sorce
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-15 11:26 EST by Petr Tuma
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-22 09:37:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Petr Tuma 2005-01-15 11:26:02 EST
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.
Comment 1 James J. Moore 2005-04-12 13:38:26 EDT
Found exactly the same problem with greatly-reduced list of actions for success
list.
Comment 2 James J. Moore 2005-04-14 17:13:22 EDT
   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.
Comment 3 James J. Moore 2005-04-15 15:00:03 EDT
   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.
Comment 4 Matthew Miller 2005-04-26 11:28:08 EDT
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.
Comment 5 Petr Tuma 2005-06-14 08:41:40 EDT
Verified the presence of this bug in samba 3.0.10 from Fedora Core 3.
Comment 6 Matthew Miller 2006-07-10 16:41:42 EDT
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!
Comment 7 Simo Sorce 2007-10-22 09:37:06 EDT
FC3 is obsolete, now closing as WONTFIX, it should be working in later Fedora
releases.

Note You need to log in before you can comment on or make changes to this bug.