On Mon Jul 20, 2026 at 10:15 PM CEST, Paul Moore wrote: > 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.
I don't think we should do that in v6 though. What you're describing affects all other xattr kfuncs. That's a broader discussion we should have separately when folks are back from vacation, and more importantly involve FS folks where the code currently lives. As you say yourself, the lines are blurry, xattrs are as much a filesystem concept. So I wouldn't burden David with it right now. David, just respin addressing all other comments and the CI issue.
