On Tue, Apr 08, 2025 at 10:55:07AM +0200, Christian Brauner wrote:
> On Mon, Apr 07, 2025 at 06:00:07PM +0200, Jan Kara wrote:
> > Hello!
> >
> > Recently I've got a question from a user about the following:
> >
> > # unshare --mount swapon /dev/sda3
> > # cat /proc/swaps
> > Filename Type Size Used Priority
> > /sda3 partition 2098152 0 -2
> >
> > Now everything works as expected here AFAICS. When namespace gets created
> > /dev mount is cloned into it. When swapon exits, the namespace is
> > destroyed and /dev mount clone is detached (no parent, namespace NULL).
That's not the issue you're seeing here though
> > Hence when d_path() crawls the path it stops at the mountpoint root and
> > exits. There's not much we can do about this but when discussing the
> > situation internally, Michal proposed that d_path() could append something
> > like "(detached)" to the path string - similarly to "(deleted)". That could
> > somewhat reduce the confusion about such paths? What do people think about
> > this?
>
> You can get into this situation in plenty of other ways. For example by
> using detached mount via open_tree(OPEN_TREE_CLONE) as layers in
> overlayfs. Or simply:
>
> int fd;
> char dpath[PATH_MAX];
>
> fd = open_tree(-EBADF, "/var/lib/fwupd", OPEN_TREE_CLONE);
> dup2(fd, 500);
> close(fd);
> readlink("/proc/self/fd/500", dpath, sizeof(dpath));
> printf("dpath = %s\n", dpath);
>
> Showing "(detached)" will be ambiguous just like "(deleted)" is. If that
> doesn't matter and it's clearly documented then it's probably fine. But
> note that this will also affect /proc/<pid>/fd/ as can be seen from the
> above example.
The other downside is that it will still be quite opaque because the
user will have to be aware of the concept of a detached mount. So it's
mostly useful for administrators tbh.
In general, I think it needs to be made clear to userspace that paths
shown in such tables are open()-able in the best case and decorative or
even misleading in the worst case.
The swap case is particularly ugly because it's a kernel-internal open
so in essence you might be located in a namespace where you can't even
even possibly reach that path.
In the
unshare --mount swapon /dev/sda3
exit
example you're lucky. If you're on the host then you can reasonably
guess and go "Oh, this is probably a fscked path we could look at /dev"
and parse through /dev/ to find "sda3" but that's a risky game even in
that case.
If you're in a container however that /proc/swaps output is completely
useless as there surely (unless you have a very broken container) won't
be a devtmpfs mount in there at all so that device isn't reachable at
all. Same for files.
In short, that output is purely diagnostic at best.
