Hi Amir,
On 2/6/24 10:24 PM, Amir Goldstein wrote:
> FUSE server calls the FUSE_DEV_IOC_BACKING_OPEN ioctl with a backing file
> descriptor. If the call succeeds, a backing file identifier is returned.
>
> A later change will be using this backing file id in a reply to OPEN
> request with the flag FOPEN_PASSTHROUGH to setup passthrough of file
> operations on the open FUSE file to the backing file.
>
> The FUSE server should call FUSE_DEV_IOC_BACKING_CLOSE ioctl to close the
> backing file by its id.
>
> This can be done at any time, but if an open reply with FOPEN_PASSTHROUGH
> flag is still in progress, the open may fail if the backing file is
> closed before the fuse file was opened.
>
> Setting up backing files requires a server with CAP_SYS_ADMIN privileges.
> For the backing file to be successfully setup, the backing file must
> implement both read_iter and write_iter file operations.
>
> The limitation on the level of filesystem stacking allowed for the
> backing file is enforced before setting up the backing file.
>
> Signed-off-by: Alessio Balsini <balsini@xxxxxxxxxxx>
> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
> ---
[...]
> +int fuse_backing_close(struct fuse_conn *fc, int backing_id)
> +{
> + struct fuse_backing *fb = NULL;
> + int err;
> +
> + pr_debug("%s: backing_id=%d\n", __func__, backing_id);
> +
> + /* TODO: relax CAP_SYS_ADMIN once backing files are visible to lsof */
> + err = -EPERM;
> + if (!fc->passthrough || !capable(CAP_SYS_ADMIN))
> + goto out;
Sorry for the late comment as I started reading this series these days.
I don't understand why CAP_SYS_ADMIN is required for the fuse server,
though I can understand it's a security constraint. I can only find
that this constraint is newly added since v14, but failed to find any
related discussion or hint.
Besides, is there any chance relaxing the constraint to
ns_capable(CAP_SYS_ADMIN), as FUSE supports FS_USERNS_MOUNT, i.e.
support passthrough mode in user namespace?
--
Thanks,
Jingbo
