On Mon 16-07-18 16:29:42, Steve Grubb wrote: > Hello, > > On Monday, July 16, 2018 11:26:53 AM EDT Jan Kara wrote: > > On Mon 16-07-18 18:50:11, Matthew Bobrowski wrote: > > > Currently, the fanotify API does not provide a means for user space > > > programs to register and receive events specifically when a file has been > > > opened with the intent to be executed. Two new event flags FAN_EXEC and > > > FAN_EXEC_PERM have been introduced to the fanotify API along with updates > > > to the generic filesystem notification hooks fsnotify_open and > > > fsnotify_perm in order to support this capability. > > > > > > Signed-off-by: Matthew Bobrowski <mbobrowski@xxxxxxxxxxxxxx> > > > > I miss one important part in this changelog: Why do you need this feature? > > Monitoring for read would be enough after all... > > There are several reasons that I can think of. There are lots of file > accesses. It is possible to guess which one is the beginning of an execve, > but you really don't know. Apps can be started in so many ways. They can be > run from the runtime linker, they have LD_PRELOAD, they can have an > unexpected interpreter, they can be statically linked, they can be a script > which may present a new pattern of file accesses. With all the variations in > how programs can start up, it would be nice to have one anchor that > unambiguously says we are overlaying this pid with a whole new app and forget > everything you knew about the pid. And the access pattern can be accurately > watched because we always have a marker to start the sequence. I don't quite buy your "marker that pid is starting from scratch" argument. Firstly, you'd have to place fanotify watches on all executables in your system to even have a chance to tell that, secondly, the process does not quite start a new - it still inherits some stuff from the old process like open file descriptors... So I understand exec might be interesting for audit purposes but then you should watch it using audit and not fanotify which is for handling / mediating filesystem accesses. And when you are looking at filesystem accesses, then there's no real difference between exec and read which is exactly why I'm not sure why the new feature is being added. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
