1. 24 Jun, 2009 2 commits
    • Al Viro's avatar
      Fix rule eviction order for AUDIT_DIR · 916d7576
      Al Viro authored
      If syscall removes the root of subtree being watched, we
      definitely do not want the rules refering that subtree
      to be destroyed without the syscall in question having
      a chance to match them.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Eric Paris's avatar
      Audit: clean up all op= output to include string quoting · 9d960985
      Eric Paris authored
      A number of places in the audit system we send an op= followed by a string
      that includes spaces.  Somehow this works but it's just wrong.  This patch
      moves all of those that I could find to be quoted.
      Change From: type=CONFIG_CHANGE msg=audit(1244666690.117:31): auid=0 ses=1
      subj=unconfined_u:unconfined_r:auditctl_t:s0-s0:c0.c1023 op=remove rule
      key="number2" list=4 res=0
      Change To: type=CONFIG_CHANGE msg=audit(1244666690.117:31): auid=0 ses=1
      subj=unconfined_u:unconfined_r:auditctl_t:s0-s0:c0.c1023 op="remove rule"
      key="number2" list=4 res=0
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
  2. 12 Jun, 2009 1 commit
  3. 21 Apr, 2009 1 commit
  4. 05 Apr, 2009 1 commit
  5. 04 Jan, 2009 2 commits
  6. 15 Nov, 2008 1 commit
    • Al Viro's avatar
      Fix inotify watch removal/umount races · 8f7b0ba1
      Al Viro authored
      Inotify watch removals suck violently.
      To kick the watch out we need (in this order) inode->inotify_mutex and
      ih->mutex.  That's fine if we have a hold on inode; however, for all
      other cases we need to make damn sure we don't race with umount.  We can
      *NOT* just grab a reference to a watch - inotify_unmount_inodes() will
      happily sail past it and we'll end with reference to inode potentially
      outliving its superblock.
      Ideally we just want to grab an active reference to superblock if we
      can; that will make sure we won't go into inotify_umount_inodes() until
      we are done.  Cleanup is just deactivate_super().
      However, that leaves a messy case - what if we *are* racing with
      umount() and active references to superblock can't be acquired anymore?
      We can bump ->s_count, grab ->s_umount, which will almost certainly wait
      until the superblock is shut down and the watch in question is pining
      for fjords.  That's fine, but there is a problem - we might have hit the
      window between ->s_active getting to 0 / ->s_count - below S_BIAS (i.e.
      the moment when superblock is past the point of no return and is heading
      for shutdown) and the moment when deactivate_super() acquires
      We could just do drop_super() yield() and retry, but that's rather
      antisocial and this stuff is luser-triggerable.  OTOH, having grabbed
      ->s_umount and having found that we'd got there first (i.e.  that
      ->s_root is non-NULL) we know that we won't race with
      So we could grab a reference to watch and do the rest as above, just
      with drop_super() instead of deactivate_super(), right? Wrong.  We had
      to drop ih->mutex before we could grab ->s_umount.  So the watch
      could've been gone already.
      That still can be dealt with - we need to save watch->wd, do idr_find()
      and compare its result with our pointer.  If they match, we either have
      the damn thing still alive or we'd lost not one but two races at once,
      the watch had been killed and a new one got created with the same ->wd
      at the same address.  That couldn't have happened in inotify_destroy(),
      but inotify_rm_wd() could run into that.  Still, "new one got created"
      is not a problem - we have every right to kill it or leave it alone,
      whatever's more convenient.
      So we can use idr_find(...) == watch && watch->inode->i_sb == sb as
      "grab it and kill it" check.  If it's been our original watch, we are
      fine, if it's a newcomer - nevermind, just pretend that we'd won the
      race and kill the fscker anyway; we are safe since we know that its
      superblock won't be going away.
      And yes, this is far beyond mere "not very pretty"; so's the entire
      concept of inotify to start with.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Acked-by: default avatarGreg KH <greg@kroah.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  7. 23 Oct, 2008 1 commit
  8. 17 May, 2008 1 commit
  9. 15 Feb, 2008 2 commits
  10. 21 Oct, 2007 1 commit
    • Al Viro's avatar
      [PATCH] audit: watching subtrees · 74c3cbe3
      Al Viro authored
      New kind of audit rule predicates: "object is visible in given subtree".
      The part that can be sanely implemented, that is.  Limitations:
      	* if you have hardlink from outside of tree, you'd better watch
      it too (or just watch the object itself, obviously)
      	* if you mount something under a watched tree, tell audit
      that new chunk should be added to watched subtrees
      	* if you umount something in a watched tree and it's still mounted
      elsewhere, you will get matches on events happening there.  New command
      tells audit to recalculate the trees, trimming such sources of false
      Note that it's _not_ about path - if something mounted in several places
      (multiple mount, bindings, different namespaces, etc.), the match does
      _not_ depend on which one we are using for access.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>