From: Giuseppe Scrivano <gscrivan@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org
Subject: Re: [PATCH 2/2] erofs: add ioctl to retrieve the backing source file descriptor
Date: Wed, 08 Jul 2026 17:20:39 +0200 [thread overview]
Message-ID: <87se5t7bjs.fsf@redhat.com> (raw)
In-Reply-To: <CALCETrVE0g-qKC079K4Ch=26VH6R+q1tXVU7HiN_Og9o1zzpow@mail.gmail.com> (Andy Lutomirski's message of "Wed, 8 Jul 2026 07:55:25 -0700")
Andy Lutomirski <luto@amacapital.net> writes:
> On Wed, Jul 8, 2026 at 2:36 AM Giuseppe Scrivano <gscrivan@redhat.com> 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
prev parent reply other threads:[~2026-07-08 15:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 9:34 [PATCH 0/2] erofs: fd-based source and backing file introspection Giuseppe Scrivano
2026-07-08 9:34 ` [PATCH 1/2] erofs: accept source file descriptor via fsconfig Giuseppe Scrivano
2026-07-08 12:45 ` Gao Xiang
2026-07-08 9:34 ` [PATCH 2/2] erofs: add ioctl to retrieve the backing source file descriptor Giuseppe Scrivano
2026-07-08 12:51 ` Gao Xiang
2026-07-08 14:55 ` Andy Lutomirski
2026-07-08 15:20 ` Giuseppe Scrivano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87se5t7bjs.fsf@redhat.com \
--to=gscrivan@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=luto@amacapital.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox