Re: race between vfs_rename and do_linkat (mv and link)

From: Al Viro <viro@zeniv.linux.org.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Xavier Roche <xavier.roche@algolia.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: race between vfs_rename and do_linkat (mv and link)
Date: Tue, 15 Feb 2022 16:18:44 +0000	[thread overview]
Message-ID: <YgvSZB9Akl7FBqPX@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <YgvPbljmJXsR7ESt@zeniv-ca.linux.org.uk>

On Tue, Feb 15, 2022 at 04:06:06PM +0000, Al Viro wrote:

> Worse, you need to deal with the corner cases.  "/" or anything ending on
> "." or ".." can be rejected (no links to directories) and thankfully we
> do not allow AT_EMPTY for linkat(2), but...  procfs symlinks are in the

That'd be AT_EMPTY_PATH, obviously, and unfortunately we do allow that.
Which brings another fun case to deal with.  Same problem with "what's the
parent of that thing and how do we make it stable?"...

Oh, and you need to cope with O_TMPFILE ones as well - both for that and
for procfs symlinks to them.  Which is fine from the vfs_link() POV (see
I_LINKABLE check in there), but the locking is outside of that, so we
need to deal with that joy.  And _there_ you have no parent at all - what
could it be, anyway?  So we'd need to decide what to lock.  *AND* we have
the possibility of another thread doing link(2) on what used to be
O_TMPFILE, which would give it a parent by the time we get to doing
the actual operation...