On Mon, Sep 18, 2023 at 7:20 AM Han-Wen Nienhuys <[email protected]> wrote: > Hi there, > > I'm troubleshooting a performance problem in FUSE filesystems. At > $DAYJOB, we have a number of FUSE file systems used for development > (eg. serving source code), and we have an auditd configuration so the > security team can keep tabs on nefarious activity. > > We see that the audit subsystem generates copious xattr reads for > "security.capability". For FUSE, those xattr reads are passed back > into userspace, which is expensive because of the extra context > switch. In our case, the FUSE filesystems universally reply ENODATA to > these reads. It looks very straightforward to change FUSE to > optionally filter the xattr reads in the FUSE driver, but I wanted to > make sure that that is the fundamentally correct approach to solve our > problem. > > We can see that the xattr is read for all manner of files, including > directories. When I read through the source code, it looks like this > originates from get_vfs_caps_from_disk() > (https://elixir.bootlin.com/linux/v6.5.3/source/security/commoncap.c#L654), > which reads the capabilities regardless of file type or mode. > > Has anyone ever considered making this conditional on the mode or > filetype? AFAICT, both are available at this call-site.
I would like someone to double check that the only time the file capabilities are used is when it is a regular file and marked as an executable, but if that is the case I think it would be okay. We would also want to ensure that we have proper logging when the file capabilities are changed, regardless of the mode bits as one could modify the file capabilities and then set the executable bit. -- paul-moore.com
