Re: [PATCH bpf-next 2/2] selftests/bpf: Extend test fs_kfuncs to cover security.bpf xattr names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Christoph, 

> On Oct 22, 2024, at 11:45 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> 
> On Mon, Oct 21, 2024 at 03:24:30PM +0200, Christian Brauner wrote:
>> On Thu, Oct 17, 2024 at 08:03:51AM -0700, Christoph Hellwig wrote:
>>> On Wed, Oct 16, 2024 at 04:51:37PM +0200, Christian Brauner wrote:
>>>>> 
>>>>> I think that getting user.* xattrs from bpf hooks can still be useful for
>>>>> introspection and other tasks so I'm not convinced we should revert that
>>>>> functionality but maybe it is too easy to misuse? I'm not really decided.
>>>> 
>>>> Reading user.* xattr is fine. If an LSM decides to built a security
>>>> model around it then imho that's their business and since that happens
>>>> in out-of-tree LSM programs: shrug.
>>> 
>>> By that argument user.kfuncs is even more useless as just being able
>>> to read all xattrs should be just as fine.
>> 
>> bpf shouldn't read security.* of another LSM or a host of other examples...
> 
> Sorry if I was unclear, but this was all about user.*.

Given bpf kfuncs can read user.* xattrs for almost a year now, I think we 
cannot simply revert it. We already have some users using it. 

Instead, we can work on a plan to deprecated it. How about we add a 
WARN_ON_ONCE as part of this patchset, and then remove user.* support 
after some time?

Thanks,
Song




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux