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

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

On Wed, Jan 15, 2025 at 10:56:08AM -0800, Boris Burkov wrote:
> Hello,
> 
> If we run the following C code:
> 
> unshare(CLONE_NEWNS);
> int fd = open("/dev/loop0", O_RDONLY)
> unshare(CLONE_NEWNS);
> 
> Then after the second unshare, the mount hierarchy created by the first
> unshare is fully dereferenced and gets torn down, leaving the file
> pointed to by fd with a broken dentry.

No, it does not.  dentry is just fine and so's mount - it is not
attached to anything, but it's alive and well.

> Specifically, subsequent calls to d_path on its path resolve to
> "/loop0".

> My question is:
> Is this expected behavior with respect to mount reference counts and
> namespace teardown?

Yes.  Again, mount is still alive; it is detached, but that's it.

> If I mount a filesystem and have a running program with an open file
> descriptor in that filesystem, I would expect unmounting that filesystem
> to fail with EBUSY, so it stands to reason that the automatic unmount
> that happens from tearing down the mount namespace of the first unshare
> should respect similar semantics and either return EBUSY or at least
> have the lazy umount behavior and not wreck the still referenced mount
> objects.

Lazy umount is precisely what is happening.  Referenced mount object is
there as long as it is referenced.