Andy Lutomirski [off-list ref] writes:

On Wed, Jul 8, 2026 at 2:36 AM Giuseppe Scrivano [off-list ref] wrote:

quoted

Add EROFS_IOC_GET_SOURCE_FD ioctl that returns a file descriptor to the
backing image file for file-backed erofs mounts.

What’s the use case?

the use case is to reuse EROFS mounts across multiple composefs mounts
without needing a user space daemon to keep the fd alive.  The advantage
is that we can share the same superblock across multiple overlay mounts,
instead of limiting the sharing to the same backing file.

In any event, this seems to have potential security and API-oddity implications.

1. That capable(CAP_SYS_ADMIN) seems critical — otherwise a task that
is admin in a userns can get an fd to a backing file *outside* its
container or to an otherwise inaccessible file.  It at least needs a
comment IMO.

thanks, I'll add that.

2.  This series appears to fully round-trip the struct file. That
means that f_cred and mode are preserved. This seems strange and may
have all kinds of accidental effects. For mode in parallel, if the
program that mounts the backing store opened it for write, then this
API gives a writable fd, which seems like an odd choice for a
filesystem that literally has read only in the name.
The OVL variant has these issues to a lesser extent due to the fact
that it returns an O_PATH fd instead of an actual open file.

I didn't think much of the file mode as I assumed requiring
CAP_SYS_ADMIN was enough.  I'll change the file mode to O_RDONLY and use
current_cred() to open it.  Would that be enough?

Thanks,
Giuseppe