Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <3492fa76339672ccc48995ccf934744c63db4b80.camel@kernel.org>
Subject: Re: allowing for a completely cached umount(2) pathwalk
From:   Jeff Layton <jlayton@kernel.org>
To:     Christian Brauner <brauner@kernel.org>,
        Al Viro <viro@zeniv.linux.org.uk>
Cc:     Trond Myklebust <trondmy@hammerspace.com>,
        Neil Brown <neilb@suse.de>,
        Dave Wysochanski <dwysocha@redhat.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        linux-nfs <linux-nfs@vger.kernel.org>,
        David Howells <dhowells@redhat.com>,
        Christoph Hellwig <hch@lst.de>
Date:   Fri, 14 Apr 2023 06:09:46 -0400
In-Reply-To: <20230414-leihgabe-eisig-71fb7bb44d49@brauner>
References: <95ee689c76bf034fa2fe9fade0bccdb311f3a04f.camel@kernel.org>
         <168142566371.24821.15867603327393356000@noble.neil.brown.name>
         <20230414024312.GF3390869@ZenIV>
         <8EC5C625-ACD6-4BA0-A190-21A73CCBAC34@hammerspace.com>
         <20230414035104.GH3390869@ZenIV>
         <20230414-leihgabe-eisig-71fb7bb44d49@brauner>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Fri, 2023-04-14 at 11:41 +0200, Christian Brauner wrote:
> On Fri, Apr 14, 2023 at 04:51:04AM +0100, Al Viro wrote:
> > On Fri, Apr 14, 2023 at 03:28:45AM +0000, Trond Myklebust wrote:
> >=20
> > > We already have support for directory file descriptors when mounting =
with move_mount(). Why not add a umountat() with similar support for the un=
mount side?
> > > Then add a syscall to allow users with (e.g.) the CAP_DAC_OVERRIDE pr=
ivilege to convert the mount-id into an O_PATH file descriptor.
> >=20
> > You can already do umount -l /proc/self/fd/69 if you have a descriptor.
>=20
> Way back when we put together stuff for [2] we had umountat() as an item
> but decided against it because it's mostely useful when used as AT_EMPTY_=
PATH.
>=20
> umount("/proc/self/fd/<nr>", ...) is useful when you don't trust the
> path and you need to resolve it with lookup restrictions. Then path
> resolution restrictions of openat2() can be used to get an fd. Which can
> be passed to umount().
>=20
> I need to step outside so this is a halfway-out-the-door thought but
> given your description of the problem Jeff, why doesn't the following
> work (Just sketching this, you can't call openat2() like that.):
>=20
>         fd_mnt =3D openat2("/my/funky/nfs/share/mount", RESOLVE_CACHED)
>         umount("/proc/self/fd/fd_mnt", MNT_DETACH)

Something like that might work. A RESOLVE_CACHED flag is something that
would involve more than just umount(2) though. That said, it could be
useful in other situations.

>=20
> > Converting mount-id to O_PATH... might be an interesting idea.
>=20
> I think using mount-ids would be nice and fwiw, something we considered
> as an alternative to umountat(). Not just can they be gotten from
> /proc/<pid>/mountinfo but we also do expose the mount id to userspace
> nowadays through:
>=20
>         STATX_MNT_ID
>         __u64	stx_mnt_id;
>=20
> which also came out of [2]. And it should be safe to do via
> AT_STATX_DONT_SYNC:
>=20
>         statx(my_cached_fd, AT_NO_AUTOMOUNT|AT_SYMLINK_NOFOLLOW|AT_STATX_=
DONT_SYNC)
>=20
> using STATX_ATTR_MOUNT_ROOT to identify a potential mountpoint. Then
> pass that mount-id to the new system call.
>=20
> [2]: https://github.com/uapi-group/kernel-features

This is generating a lot of good ideas! Maybe we should plan to discuss
this further at LSF/MM?

--=20
Jeff Layton <jlayton@kernel.org>