> 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 thing that's come up recently that we can't detect with Talpa: Can fanotify differentiate between an execute and a normal open for reading? If it can differentiate, could it send that information in the event_metadata? -- Douglas Leeder -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html