On Mon, Jul 20, 2026 at 2:27 PM Kumar Kartikeya Dwivedi <[email protected]> wrote: > On Mon Jul 20, 2026 at 8:12 PM CEST, David Windsor wrote: > > On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <[email protected]> wrote: > >> > >> > >> I'm sorry David, now that I'm seeing this function again, especially > >> with the LSM specific bits extracted into a LSM function, this absolutely > >> belongs somewhere under security/. It's only callable from within a > >> BPF LSM callback and all it does outside of some BPF pointer boilerplate > >> is call right back into a LSM helper function. > >> > >> If the BPF maintainers aren't willing to accept that, then we will all > >> need to find another way. > > > > Where this code lands doesn't matter to me, so I'll stay out of the > > decision of where it lives.
Yes, you're caught up in some territorial wrangling that goes a fair bit beyond what you're looking to accomplish. My apologies for my half of that, it is an unfortunate part of upstream kernel development. > > If this kfunc goes to security/, would we also want to move eg > > bpf_set_dentry_xattr similarly? > > > > I'll roll v6 of this series meanwhile and we'll see what the BPF > > maintainers say. Thanks. Fortunately, it should be easy enough to move the kfunc around, that's likely one of the smaller changes needed in v6. > I don't think there was any preference expressed from the BPF side. Look at the second patch in the v4 patchset, you'll see a preference. > Logically, > one cannot be faulted for adding a kfunc to set the xattr for inode in the > same > file where similar kfuncs to set xattr on other FS objects / entities exist. First off, I can't say that the existing BPF kfuncs intended for use within a BPF LSM program are in a good location. Unlike every other LSM which locates its code under security, the BPF LSM devs have chosen to locate their associated code all over the place. Some of that happened before I was responsible for the LSM framework, and some of that which has happened afterwards has likely intentionally avoided traditional LSM review. Unfortunately, this has muddied things with respect to what is possible generally in BPF versus what is possible only when the BPF LSM is enabled; we just recently saw where this was arguably the root cause of an exploitable vulnerability. > The question about bpf_set_dentry_xattr is thus valid. It's a very valid question. It is my opinion that kfuncs which are only intended to be called from within BPF LSMs should be located under security/, just like every other LSM. If there is a kfunc that is generally useful from other contexts, that is a different story, but in the bpf_set_dentry_xattr() case, it is explicitly only useful for setting 'security.bpf.*' xattrs. -- paul-moore.com
