On Thu 07-11-24 19:13:23, Song Liu wrote: > > On Nov 7, 2024, at 2:48 AM, Jan Kara <jack@xxxxxxx> wrote: > > 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? > > I have "flags" in fanotify_fastpath_ops. In an earlier version of my > local code, I actually have "SYS_ADMIN_ONLY" flag that specifies some > filters are only available to users with CAP_SYS_ADMIN. I removed this > flag later before sending the first RFC for simplicity. > > The model here (fast path loaded in kernel modules) is similar to > different TCP congestion control algorithms. Regular user can choose > which algorithm to use for each TCP connection. This model is > straightforward because the kernel modules are global. With BPF, we > have the option not to add the fast path to a global list, so that > whoever loads the fast path can attach it to specific group (I didn't > include this model in the RFC). > > For the first version, I think a SYS_ADMIN_ONLY flag would be good > enough? Yes, initially that should be enough. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
