Andy Lutomirski <[email protected]> writes: > On Wed, Jul 8, 2026 at 2:36 AM Giuseppe Scrivano <[email protected]> wrote: >> >> 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
