Re: Possible bug with open between unshare(CLONE_NEWNS) calls

[Al Viro <viro@zeniv.linux.org.uk>]

On Wed, Jan 15, 2025 at 08:52:41PM -0800, Boris Burkov wrote:
> So in your opinion, what is the bug here?
> 
> btrfs started using d_path and checking that the device source file was
> in /dev, to avoid putting nonsense like /proc/self/fd/3 into the mount
> table, where it makes userspace fall over. 
>
> (https://bugzilla.suse.com/show_bug.cgi?id=1230641)
> 
> I'd be loathe to call the userspace program hitting the
> 'unshare; open; unshare' sequence buggy, as we don't fail any of the
> syscalls in a particularly sensible way. And if you use unshare -m, you
> now have to vet the program you call doesn't use unshare itself?
> 
> You've taught me that d_path is working as intended in the face of the
> namespace lifetime, so we can't rely on it to produce the "real"
> (original?) path, in general.
> 
> So, to me, that leaves the bug as
> "btrfs shouldn't assume/validate that device files will be in /dev."
> 
> We can do the d_path resolution thing anyway to cover the common case,
> in the bugzilla, but shouldn't fail on something like /loop0 when that
> is what we get out of d_path?

You are asking for a pathname associated with an open file on a mount
that is not within your namespace.  "The path from the root of whatever
namespace it's in starts with /dev" is an odd predicate to check.

Note that the same namespace may have a very different meaning in your
namespace, so...  I'd say that predicate is very likely not doing what
your userland expects anyway.

What is that code trying to do?  is_good_path() looks very... misguided.