[lkml]   [2008]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] 0/11 fanotify: fscking all notifiction and file access system (intended for antivirus scanning and file indexers)
    > It all starts when 'something' registers a group.  Registering a group
    > is as simple as 'echo "open_grp 50 0x10" > /security/fanotify/register.

    I thought the operation was usually called "mkdir" which also nicely
    deals with races and exclusion.

    > open_grp is just the name of the group, 50 is the priority (only
    > interesting for blocking/access events, will describe later) and 0x10 is
    > FAN_OPEN. If one wanted open and close you would use 0x1c = (FAN_OPEN |
    > FAN_CLOSE). Inside the kernel this creates the new directory called

    How do you change group on the fly in this model ?

    > The listener process will get a string that looks like "fd=10 cookie=0
    > mask=10." This is telling the listener process that a new fd has been
    > created, #10. The cookie (if this notification required an access
    > decision) was 0 and the mask of the event was 0x10 (FAN_OPEN.)

    Ok that is foul as an interface, utterly gross. I guess it would be
    useful to also be able to not want fds

    > event is added to the group->access_list AND to the group->event_list.
    > The original process is then blocked for a (now fixed 5 second) timeout
    > waiting for the event to get a non-zero event->response on the
    > group->access_waitq.

    That raises security and correctness questions with things like "make it
    swap hard" attacks. Given that any timeout can be configured its not a
    big deal. Do need to handle process death or close of the notification

    I think the mechanism is pretty sound. There are some "how do I" cases to
    do with open and watching for events when I want to rescan something as
    it has been dirty for a while. I'm not sure mmap dirty properly updates
    the file mtime - that wants doing anyway for backups tho so is the real

    The userspace API you propoe should however be taken out and shot, then
    buried with a stake through its heart, holy water in its mouth and its
    head cut off, at midnight in a pentacle at a crossroads in the presence
    of a priest.

    The two discussions are fortunately orthogonal. Is there any reason you
    can't use the socket based notification model - that gives you a much
    more natural way to express the thing

    bind(AF_FAN, group=foo+flags etc, PF_FAN);

    fd = accept(old_fd, &addr[returned info])


    as well as fairly natural and importantly standards defined semantics for
    poll including polling for a new file handles, for reconfiguration of
    stuff via get/setsockopt (which do pass stuff like object sizes unlike
    ioctls) and for reading/writing data.

    Its not quite the same as a normal socket given you accept and get a non
    socket fd with the info you need in the return address area but its much
    closer than the rather mad file system proposal.

    It would certainly be sane enough to, for example, start righting
    scanners in stuff like python-twisted or ruby on rails (not that this is
    neccessarily a good thing!)


     \ /
      Last update: 2008-09-26 23:39    [W:0.024 / U:5.184 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site