Skip to content

L
linux
Switch branch/tag
  1. 07 Dec, 2010 9 commits
    • Lino Sanfilippo's avatar
      fanotify: Introduce FAN_NOFD · e9a3854f
      Lino Sanfilippo authored 
      FAN_NOFD is used in fanotify events that do not provide an open file
descriptor (like the overflow_event).
Signed-off-by: default avatarLino Sanfilippo <LinoSanfilippo@gmx.de>
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      e9a3854f
    • Eric Paris's avatar
      fanotify: do not leak user reference on allocation failure · 26379198
      Eric Paris authored 
      If fanotify_init is unable to allocate a new fsnotify group it will
return but will not drop its reference on the associated user struct.
Drop that reference on error.
Reported-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      26379198
    • Eric Paris's avatar
      inotify: stop kernel memory leak on file creation failure · a2ae4cc9
      Eric Paris authored 
      If inotify_init is unable to allocate a new file for the new inotify
group we leak the new group.  This patch drops the reference on the
group on file allocation failure.
Reported-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
cc: stable@kernel.org
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      a2ae4cc9
    • Lino Sanfilippo's avatar
      fanotify: on group destroy allow all waiters to bypass permission check · 09e5f14e
      Lino Sanfilippo authored 
      When fanotify_release() is called, there may still be processes waiting for
access permission. Currently only processes for which an event has already been
queued into the groups access list will be woken up.  Processes for which no
event has been queued will continue to sleep and thus cause a deadlock when
fsnotify_put_group() is called.
Furthermore there is a race allowing further processes to be waiting on the
access wait queue after wake_up (if they arrive before clear_marks_by_group()
is called).
This patch corrects this by setting a flag to inform processes that the group
is about to be destroyed and thus not to wait for access permission.

[additional changelog from eparis]
Lets think about the 4 relevant code paths from the PoV of the
'operator' 'listener' 'responder' and 'closer'.  Where operator is the
process doing an action (like open/read) which could require permission.
Listener is the task (or in this case thread) slated with reading from
the fanotify file descriptor.  The 'responder' is the thread responsible
for responding to access requests.  'Closer' is the thread attempting to
close the fanotify file descriptor.

The 'operator' is going to end up in:
fanotify_handle_event()
  get_response_from_access()
    (THIS BLOCKS WAITING ON USERSPACE)

The 'listener' interesting code path
fanotify_read()
  copy_event_to_user()
    prepare_for_access_response()
      (THIS CREATES AN fanotify_response_event)

The 'responder' code path:
fanotify_write()
  process_access_response()
    (REMOVE A fanotify_response_event, SET RESPONSE, WAKE UP 'operator')

The 'closer':
fanotify_release()
  (SUPPOSED TO CLEAN UP THE REST OF THIS MESS)

What we have today is that in the closer we remove all of the
fanotify_response_events and set a bit so no more response events are
ever created in prepare_for_access_response().

The bug is that we never wake all of the operators up and tell them to
move along.  You fix that in fanotify_get_response_from_access().  You
also fix other operators which haven't gotten there yet.  So I agree
that's a good fix.
[/additional changelog from eparis]

[remove additional changes to minimize patch size]
[move initialization so it was inside CONFIG_FANOTIFY_PERMISSION]
Signed-off-by: default avatarLino Sanfilippo <LinoSanfilippo@gmx.de>
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      09e5f14e
    • Lino Sanfilippo's avatar
      fanotify: Dont allow a mask of 0 if setting or removing a mark · 1734dee4
      Lino Sanfilippo authored 
      In mark_remove_from_mask() we destroy marks that have their event mask cleared.
Thus we should not allow the creation of those marks in the first place.
With this patch we check if the mask given from user is 0 in case of FAN_MARK_ADD.
If so we return an error. Same for FAN_MARK_REMOVE since this does not have any
effect.
Signed-off-by: default avatarLino Sanfilippo <LinoSanfilippo@gmx.de>
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      1734dee4
    • Lino Sanfilippo's avatar
      fanotify: correct broken ref counting in case adding a mark failed · fa218ab9
      Lino Sanfilippo authored 
      If adding a mount or inode mark failed fanotify_free_mark() is called explicitly.
But at this time the mark has already been put into the destroy list of the
fsnotify_mark kernel thread. If the thread is too slow it will try to decrease
the reference of a mark, that has already been freed by fanotify_free_mark().
(If its fast enough it will only decrease the marks ref counter from 2 to 1 - note
that the counter has been increased to 2 in add_mark() - which has practically no
effect.)

This patch fixes the ref counting by not calling free_mark() explicitly, but
decreasing the ref counter and rely on the fsnotify_mark thread to cleanup in
case adding the mark has failed.
Signed-off-by: default avatarLino Sanfilippo <LinoSanfilippo@gmx.de>
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      fa218ab9
    • Lino Sanfilippo's avatar
      fanotify: if set by user unset FMODE_NONOTIFY before fsnotify_perm() is called · b1085ba8
      Lino Sanfilippo authored 
      Unsetting FMODE_NONOTIFY in fsnotify_open() is too late, since fsnotify_perm()
is called before. If FMODE_NONOTIFY is set fsnotify_perm() will skip permission
checks, so a user can still disable permission checks by setting this flag
in an open() call.
This patch corrects this by unsetting the flag before fsnotify_perm is called.
Signed-off-by: default avatarLino Sanfilippo <LinoSanfilippo@gmx.de>
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      b1085ba8
    • Eric Paris's avatar
      fanotify: remove packed from access response message · 88d60c32
      Eric Paris authored 
      Since fanotify has decided to be careful about alignment and packing
rather than rely on __attribute__((packed)) for multiarch support.
Since this attribute isn't doing anything on fanotify_response we just
drop it.  This does not break API/ABI.
Suggested-by: default avatarTvrtko Ursulin <tvrtko.ursulin@sophos.com>
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      88d60c32
    • Eric Paris's avatar
      fanotify: deny permissions when no event was sent · ecf6f5e7
      Eric Paris authored 
      If no event was sent to userspace we cannot expect userspace to respond to
permissions requests.  Today such requests just hang forever. This patch will
deny any permissions event which was unable to be sent to userspace.
Reported-by: default avatarTvrtko Ursulin <tvrtko.ursulin@sophos.com>
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      ecf6f5e7
  3. 30 Nov, 2010 2 commits
  5. 29 Nov, 2010 18 commits
  7. 28 Nov, 2010 11 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7