Hi Christian, Thanks a lot for your detailed explanation! We will revisit the design based on these comments and suggestions. One more question about a potential new kfunc bpf_get_inode_xattr(): Should it take dentry as input? IOW, should it look like: __bpf_kfunc int bpf_get_inode_xattr(struct dentry *dentry, const char *name__str, struct bpf_dynptr *value_p) { struct bpf_dynptr_kern *value_ptr = (struct bpf_dynptr_kern *)value_p; u32 value_len; void *value; int ret; if (strncmp(name__str, XATTR_USER_PREFIX, XATTR_USER_PREFIX_LEN)) return -EPERM; value_len = __bpf_dynptr_size(value_ptr); value = __bpf_dynptr_data_rw(value_ptr, value_len); if (!value) return -EINVAL; ret = inode_permission(&nop_mnt_idmap, dentry->d_inode, MAY_READ); if (ret) return ret; return __vfs_getxattr(dentry, dentry->d_inode, name__str, value, value_len); } I am asking because many security_inode_* hooks actually taking dentry as argument. So it makes sense to use dentry for kfuncs. Maybe we should call it bpf_get_dentry_xattr, which is actually the same kfunc in this set (1/2)? Thanks, Song > On Jul 29, 2024, at 6:46 AM, Christian Brauner <brauner@xxxxxxxxxx> wrote: [...] >>> Imho, what you're doing belongs into inode_permission() not into >>> security_file_open(). That's already too late and it's somewhat clear >>> from the example you're using that you're essentially doing permission >>> checking during path lookup. >> >> I am not sure I follow the suggestion to implement this with >> security_inode_permission()? Could you please share more details about >> this idea? [...]