[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2FE83412-65A5-451B-8722-E0B8035BFD30@fb.com>
Date: Tue, 30 Jul 2024 05:58:31 +0000
From: Song Liu <songliubraving@...a.com>
To: Christian Brauner <brauner@...nel.org>
CC: Song Liu <songliubraving@...a.com>, Song Liu <song@...nel.org>,
bpf
<bpf@...r.kernel.org>,
Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
LKML
<linux-kernel@...r.kernel.org>,
Kernel Team <kernel-team@...a.com>,
"andrii@...nel.org" <andrii@...nel.org>,
"eddyz87@...il.com"
<eddyz87@...il.com>,
"ast@...nel.org" <ast@...nel.org>,
"daniel@...earbox.net" <daniel@...earbox.net>,
"martin.lau@...ux.dev"
<martin.lau@...ux.dev>,
"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"jack@...e.cz" <jack@...e.cz>,
"kpsingh@...nel.org" <kpsingh@...nel.org>,
"mattbobrowski@...gle.com" <mattbobrowski@...gle.com>
Subject: Re: [PATCH bpf-next 2/2] selftests/bpf: Add tests for
bpf_get_dentry_xattr
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@...nel.org> 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?
[...]
Powered by blists - more mailing lists