On Mon, Jul 20, 2026 at 4:41 PM Paul Moore <[email protected]> wrote: > > On Mon, Jul 20, 2026 at 2:06 PM David Windsor <[email protected]> wrote: > > On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <[email protected]> wrote: > > > > > ... > > > > > +int security_lsmxattr_add(struct lsm_xattrs *xattrs, u64 lsm_id, > > > > + const char *name, const void *value, > > > > + size_t value_len) > > > > +{ > > > > + struct xattr *xattr; > > > > + void *xattr_value; > > > > + size_t name_len; > > > > + > > > > + if (!xattrs || !xattrs->xattrs || !name || !value) > > > > + return -EINVAL; > > > > > > Sashiko raised a good point about xattrs->xattrs being NULL not > > > necessarily being a good reason for -EINVAL. If xattrs is NULL, yes, > > > something has gone wrong and -EINVAL seems reasonable, but the > > > xattr->xattrs NULL case does seem like it should simply return early > > > with a value of 0 (see SELinux's handling of this case as an example). > > > > The problem is, SELinux has already set the sid by before calling > > lsm_get_xattr_slot, so we do indeed get an in-core label for the inode > > before returning early here. Returning early here from BPF would not > > mean the same thing: there is no label anywhere, in memory or on disk. > > It's important to remember that you are not always guaranteed to have > an lsm_xattrs buffer, for some filesystems that is going to be normal > and expected. In these instances the 'xattrs->xattrs' value is going > to be NULL and each LSM that provides a security_inode_init_security() > LSM callback needs to handle that condition gracefully. > > As you already know, the SELinux approach to this is to set the > in-memory inode label, but refrain from setting a presistent label > (these filesystems are typically either transient or don't have a > mechanism to allow for persistent label storage). Each BPF program > will need to decide how they want to handle this in their > security_inode_init_security() callback, but in the > security_lsmxattr_add() code where the only purpose is to populate the > lsm_xattrs strcut with the persistent BPF label/xattr, there is > nothing that can be done, it should simply return early without error. >
Makes sense. If BPF LSMs want to store an in-core label, they could just use bpf_inode_storage_get. > -- > paul-moore.com
