On Mon, Jan 20, 2025 at 1:50 PM Juntong Deng <juntong.deng@xxxxxxxxxxx> wrote: > [...] > > >> > >> Would it be a better idea for us to let each kfunc have its own > >> capability attribute? > > > > This is no different to the BPF helper function ID, which turned > > out to be not scalable. > > > > There still seems to be a difference? BPF capabilities are not > one-to-one with kfuncs, and multiple kfuncs can be bound to one > BPF capability. > > BPF capabilities are more like fine-grained versions of program types. I personally think struct_ops gives good enough fine-grained control. Therefore, I don't see a real need for a different concept. [...] > >> > >> For example, if a system administrator wants to open the features of the > >> HID-BPF driver to users, but the system administrator does not want to > >> open other BPF features to users, such as sched_ext. > > > > This appears to be a totally separate topic. > > > > Although I am not sure, I guess general fine-grained permissions > management might still be valuable (not necessarily BPF capabilities). > > I found that Andrii Nakryiko implemented something similar in > BPF Token[0]. > > Similar to SCX, BPF features are fine-grained through masks to restrict > only part of the BPF features to be opened. > > This seems to indicate that the demand for making BPF permissions > management fine-grained has always existed, and the demand for opening > only part of the BPF features will reappear in different forms. > > Maybe we do need a general fine-grained permissions management solution? I don't think it is easy to build a fine-grained permission management solution that fits most scenarios. It is better to do this via programmable interfaces, e.g. with BPF LSM. Thanks, Song > If Andrii saw this email, could you please join the discussion? > > [0]: https://lwn.net/Articles/947173/ >
