On Tue, Apr 08, 2025 at 02:04:48PM +0200, Jan Kara wrote:
> On Tue 08-04-25 13:39:28, Christian Brauner wrote:
> > 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
Uh, sorry about this weird stray sentence. Not sure how that ended up in
here. I think that was supposed to be in another mail.
> >
> > > > 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.
>
> Thanks for the insights!
>
> > 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.
>
> Yes, I know this and I was just wondering if we can at least somehow
> visibly indicate the path shown is likely unusable. If you think it would
> do more harm than good, I'm fine with that answer, I just thought I'll
> ask...
Oh yes, absolutely. It's good to bring this up. I just wonder whether
we could do better. Karel suggested using a stx_attribute and I had
pondered a statmount() extension but both have some issues though let me
pitch them nonetheless somewhat independent of the issue.
We could add a statmount() extension to mark detached mounts as being
detached. That however will only work for anonymous detached mounts,
i.e., mounts that have been created using OPEN_TREE_CLONE or fsmount().
Since statmount() uses the mount namespace rbtree to lookup mounts any
unmounted mount with mnt->mnt_ns == NULL cannot be found anymore. So
it's - currently at least - not useful to handle the /proc/swaps case.
A statx() extension would be more useful because it would work
independent of whether this is a detached mount or not. So we would
start reporting STATX_MNT_DETACHED in stx_attributes which allows
userspace to figure out that the thing was unmounted. That might be
genuinely useful.
But both solution wouldn't help with the /proc/swaps scenario because
it's not guaranteed that the file can be opened because it might be
outside the caller's mount namespace (or even deleted).
