Re: [PATCH v5 bpf-next 5/5] bpf/selftests: Add a selftest for bpf_getxattr

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

 



> >
> > Apropos __vfs_getxattr(), looks like ecryptfs_getxattr_lower()
> > is abusing it.
>
> Heh, quoting what I wrote to KP yesterday off-list about
> __vfs_getxattr():
>
> "it's [__vfs_getxattr()] exported but [afaict] it's not used in kernel
> modules. afaict it's only exposed because of ecryptfs"
>
> So right at the beginning I had already pondered whether we should just
> rip out __vfs_getxattr() from ecryptfs and unexport the helper
> completely because there's barely a reason to use it. Module/driver code
> should not use something as low-level as __vfs_getxattr() imho.
>
> Overlayfs does it correctly and uses vfs_getxattr() but maybe ecryptfs
> needs to use it for for some reason?. I haven't looked yet.
>

No reason AFAIK (CC Tyler+Miklos)

Most lower ecryptfs operations use vfs_XXX()
48b512e68571 ("ecryptfs: call vfs_setxattr() in ecryptfs_setxattr()")
fixed vfs_setxattr() which was later changed to __vfs_setxattr_locked(),
but left __vfs_getxattr(), __vfs_removexattr() and i_op->listxattr().

> > Christian, not sure if you intend to spend time of idmapped
> > mount support of ecryptfs lower layer, but anyway that's that.
>
> Not really. Remember the conversation we had with Tyler at LSFMM where
> he considered marking it deprecated. I don't think it's worth putting in
> the work.

OK, so just need a volunteer to close the security hole and
possibly unexport __vfs_getxattr().

Does anybody know of any out of tree modules that use it
for a good reason?

Thanks,
Amir.



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux