On Tue, Jul 30, 2024 at 05:58:31AM GMT, Song Liu wrote:
> 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, inode, MAY_READ);
> if (ret)
> return ret;
> return __vfs_getxattr(dentry, 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
Some filesystems (i) require access to the @dentry in their xattr
handlers (e.g. 9p) and (ii) ->get() and ->set() xattr handlers can be
called when @inode hasn't been attached to @dentry yet.
So if you allowed to call bpf_get_*_xattr() from
security_d_instantiate() to somehow retrieve xattrs from there, then you
need to pass @dentry and @inode separately and you cannot use
@dentry->d_inode because it would still be NULL.
However, I doubt you'd call bpf_get_*_xattr() from
security_d_instantiate() so imo just pass the dentry and add a check
like:
struct inode *inode = d_inode(dentry);
if (WARN_ON(!inode))
return -EINVAL;
in there.
