1. 29 10月, 2010 11 次提交
    • E
      fanotify: allow userspace to override max marks · ac7e22dc
      Eric Paris 提交于
      Some fanotify groups, especially those like AV scanners, will need to place
      lots of marks, particularly ignore marks.  Since ignore marks do not pin
      inodes in cache and are cleared if the inode is removed from core (usually
      under memory pressure) we expose an interface for listeners, with
      CAP_SYS_ADMIN, to override the maximum number of marks and be allowed to
      set and 'unlimited' number of marks.  Programs which make use of this
      feature will be able to OOM a machine.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      ac7e22dc
    • E
      fanotify: limit the number of marks in a single fanotify group · e7099d8a
      Eric Paris 提交于
      There is currently no limit on the number of marks a given fanotify group
      can have.  Since fanotify is gated on CAP_SYS_ADMIN this was not seen as
      a serious DoS threat.  This patch implements a default of 8192, the same as
      inotify to work towards removing the CAP_SYS_ADMIN gating and eliminating
      the default DoS'able status.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      e7099d8a
    • E
      fanotify: allow userspace to override max queue depth · 5dd03f55
      Eric Paris 提交于
      fanotify has a defualt max queue depth.  This patch allows processes which
      explicitly request it to have an 'unlimited' queue depth.  These processes
      need to be very careful to make sure they cannot fall far enough behind
      that they OOM the box.  Thus this flag is gated on CAP_SYS_ADMIN.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      5dd03f55
    • E
      fsnotify: implement a default maximum queue depth · 2529a0df
      Eric Paris 提交于
      Currently fanotify has no maximum queue depth.  Since fanotify is
      CAP_SYS_ADMIN only this does not pose a normal user DoS issue, but it
      certianly is possible that an fanotify listener which can't keep up could
      OOM the box.  This patch implements a default 16k depth.  This is the same
      default depth used by inotify, but given fanotify's better queue merging in
      many situations this queue will contain many additional useful events by
      comparison.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      2529a0df
    • E
      fanotify: ignore fanotify ignore marks if open writers · 5322a59f
      Eric Paris 提交于
      fanotify will clear ignore marks if a task changes the contents of an
      inode.  The problem is with the races around when userspace finishes
      checking a file and when that result is actually attached to the inode.
      This race was described as such:
      
      Consider the following scenario with hostile processes A and B, and
      victim process C:
      1. Process A opens new file for writing. File check request is generated.
      2. File check is performed in userspace. Check result is "file has no malware".
      3. The "permit" response is delivered to kernel space.
      4. File ignored mark set.
      5. Process A writes dummy bytes to the file. File ignored flags are cleared.
      6. Process B opens the same file for reading. File check request is generated.
      7. File check is performed in userspace. Check result is "file has no malware".
      8. Process A writes malware bytes to the file. There is no cached response yet.
      9. The "permit" response is delivered to kernel space and is cached in fanotify.
      10. File ignored mark set.
      11. Now any process C will be permitted to open the malware file.
      There is a race between steps 8 and 10
      
      While fanotify makes no strong guarantees about systems with hostile
      processes there is no reason we cannot harden against this race.  We do
      that by simply ignoring any ignore marks if the inode has open writers (aka
      i_writecount > 0).  (We actually do not ignore ignore marks if the
      FAN_MARK_SURV_MODIFY flag is set)
      Reported-by: NVasily Novikov <vasily.novikov@kaspersky.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      5322a59f
    • E
      fsnotify: call fsnotify_parent in perm events · 52420392
      Eric Paris 提交于
      fsnotify perm events do not call fsnotify parent.  That means you cannot
      register a perm event on a directory and enforce permissions on all inodes in
      that directory.  This patch fixes that situation.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      52420392
    • E
      fsnotify: correctly handle return codes from listeners · ff8bcbd0
      Eric Paris 提交于
      When fsnotify groups return errors they are ignored.  For permissions
      events these should be passed back up the stack, but for most events these
      should continue to be ignored.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      ff8bcbd0
    • E
      fanotify: implement fanotify listener ordering · 4231a235
      Eric Paris 提交于
      The fanotify listeners needs to be able to specify what types of operations
      they are going to perform so they can be ordered appropriately between other
      listeners doing other types of operations.  They need this to be able to make
      sure that things like hierarchichal storage managers will get access to inodes
      before processes which need the data.  This patch defines 3 possible uses
      which groups must indicate in the fanotify_init() flags.
      
      FAN_CLASS_PRE_CONTENT
      FAN_CLASS_CONTENT
      FAN_CLASS_NOTIF
      
      Groups will receive notification in that order.  The order between 2 groups in
      the same class is undeterministic.
      
      FAN_CLASS_PRE_CONTENT is intended to be used by listeners which need access to
      the inode before they are certain that the inode contains it's final data.  A
      hierarchical storage manager should choose to use this class.
      
      FAN_CLASS_CONTENT is intended to be used by listeners which need access to the
      inode after it contains its intended contents.  This would be the appropriate
      level for an AV solution or document control system.
      
      FAN_CLASS_NOTIF is intended for normal async notification about access, much the
      same as inotify and dnotify.  Syncronous permissions events are not permitted
      at this class.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      4231a235
    • E
      fsnotify: implement ordering between notifiers · 6ad2d4e3
      Eric Paris 提交于
      fanotify needs to be able to specify that some groups get events before
      others.  They use this idea to make sure that a hierarchical storage
      manager gets access to files before programs which actually use them.  This
      is purely infrastructure.  Everything will have a priority of 0, but the
      infrastructure will exist for it to be non-zero.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      6ad2d4e3
    • E
      fanotify: allow fanotify to be built · 9343919c
      Eric Paris 提交于
      We disabled the ability to build fanotify in commit 7c534773.
      This reverts that commit and allows people to build fanotify.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      9343919c
    • I
      ext4: fix compile with CONFIG_EXT4_FS_XATTR disabled · 19ef2014
      Ingo Molnar 提交于
      Commit 5dabfc78 ("ext4: rename {exit,init}_ext4_*() to
      ext4_{exit,init}_*()") causes
      
        fs/ext4/super.c:4776: error: implicit declaration of function ‘ext4_init_xattr’
      
      when CONFIG_EXT4_FS_XATTR is disabled.
      
      It renamed init_ext4_xattr to ext4_init_xattr but forgot to update the
      dummy definition in fs/ext4/xattr.h.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: N"Theodore Ts'o" <tytso@mit.edu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      19ef2014
  2. 28 10月, 2010 29 次提交