On Tue 29-10-24 16:12:40, Song Liu wrote: > fanotify fastpath handler enables handling fanotify events within the > kernel, and thus saves a trip to the user space. fanotify fastpath handler > can be useful in many use cases. For example, if a user is only interested > in events for some files in side a directory, a fastpath handler can be > used to filter out irrelevant events. > > fanotify fastpath handler is attached to fsnotify_group. At most one > fastpath handler can be attached to a fsnotify_group. The attach/detach > of fastpath handlers are controlled by two new ioctls on the fanotify fds: > FAN_IOC_ADD_FP and FAN_IOC_DEL_FP. > > fanotify fastpath handler is packaged in a kernel module. In the future, > it is also possible to package fastpath handler in a BPF program. Since > loading modules requires CAP_SYS_ADMIN, _loading_ fanotify fastpath > handler in kernel modules is limited to CAP_SYS_ADMIN. However, > non-SYS_CAP_ADMIN users can _attach_ fastpath handler loaded by sys admin > to their fanotify fds. To make fanotify fastpath handler more useful > for non-CAP_SYS_ADMIN users, a fastpath handler can take arguments at > attach time. Hum, I'm not sure I'd be fine as an sysadmin to allow arbitary users to attach arbitrary filters to their groups. I might want some filters for priviledged programs which know what they are doing (e.g. because the filters are expensive) and other filters may be fine for anybody. But overall I'd think we'll soon hit requirements for permission control over who can attach what... Somebody must have created a solution for this already? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
