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
>
> > > 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...
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
