lkml.org 
[lkml]   [2009]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: fanotify - overall design before I start sending patches
    Date
    On Friday 24 July 2009 21:13:49 Eric Paris wrote:
    > After the socket is bound events are attained using the read() syscall
    > (recv* probably also works haven't tested). This will result in the
    > buffer being filled with one or more events like this:
    >
    > struct fanotify_event_metadata {
    > __u32 event_len;
    > __s32 fd;
    > __u32 mask;
    > __u32 f_flags;
    > __s32 pid;
    > __s32 tgid;
    > __u64 cookie;
    > } __attribute__((packed));
    >
    > fd specifies the new file descriptor that was created in the context of
    > the listener. (readlink of /proc/self/fd will give you A pathname)
    > mask indicates the events type (bitwise OR of the event types listed
    > above). f_flags here is the f_flags the ORIGINAL process has the file
    > open with. pid and tgid are from the original process. cookie is used
    > when the listener needs to allow, deny, or delay the operation.

    One more thing. uid and gid (possibly whole set?) would be useful so we can
    tell which user triggered an event without having to look at the process
    which has maybe disappeared in the mean time. I _think_ uid was in the
    original proposal/idea and don't remember if it was decided we cannot get it
    deliberately, or it was omitted by accident?

    Tvrtko


    \
     
     \ /
      Last update: 2009-08-04 18:37    [W:4.159 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site