From: Al Viro <viro@zeniv.linux.org.uk>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Christian Brauner <brauner@kernel.org>,
Boris Burkov <boris@bur.io>,
linux-fsdevel@vger.kernel.org, daan.j.demeyer@gmail.com
Subject: Re: Possible bug with open between unshare(CLONE_NEWNS) calls
Date: Thu, 16 Jan 2025 21:29:12 +0000 [thread overview]
Message-ID: <20250116212912.GN1977892@ZenIV> (raw)
In-Reply-To: <98df4904-6b61-4ddb-8df2-706236afcd8e@gmx.com>
On Fri, Jan 17, 2025 at 07:39:09AM +1030, Qu Wenruo wrote:
> The original problem is that we can get very weird device path, like
> '/proc/<pid>/<fd>' or any blockdev node created by the end user, as
> mount source, which can cause various problems in mount_info for end users.
You do realize that different namespaces may very well have the same
pathname resolve to different things, right? So "userland can't open
a device pathname it sees in /proc/self/mountinfo" was not going to
be solved that way anyway...
While we are at it, it is entirely possible to have a trimmed-down
ramfs with the minimal set of static device nodes mounted on
/dev in user's namespace, with not a block device in sight - despite
having a bunch of local filesystems mounted.
next prev parent reply other threads:[~2025-01-16 21:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 18:56 Possible bug with open between unshare(CLONE_NEWNS) calls Boris Burkov
2025-01-16 4:14 ` Al Viro
2025-01-16 4:52 ` Boris Burkov
2025-01-16 5:12 ` Al Viro
2025-01-16 10:46 ` Christian Brauner
2025-01-16 21:09 ` Qu Wenruo
2025-01-16 21:29 ` Al Viro [this message]
2025-01-16 21:42 ` Qu Wenruo
2025-01-20 15:37 ` Christian Brauner
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=20250116212912.GN1977892@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=boris@bur.io \
--cc=brauner@kernel.org \
--cc=daan.j.demeyer@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
/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