Re: fanotify - overall design before I start sending patches

[Douglas Leeder <douglas.leeder-j34lQMj1tz/QT0dZR+AlfA@public.gmane.org>]

Tvrtko Ursulin wrote:
> 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?

Maybe it would be good to include in the documentation how to extract
extra information that listeners might want?

e.g.

To get the path (or an approximation), do readlink on the fd.

To get the UID/GID of the originator process, look in /proc/<PID>/????

etc.

This would provide easier answers to the questions on including extra
info in the fanotify events.

-- 
Douglas Leeder