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.
