From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from out5-smtp.messagingengine.com ([66.111.4.29]:51071 "EHLO
        out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1727700AbeKNWNW (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Wed, 14 Nov 2018 17:13:22 -0500
From: Nikolaus Rath <Nikolaus@rath.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Al Viro <viro@zeniv.linux.org.uk>, Neil Brown <neil@brown.name>
Subject: Re: Behaviour of /proc/self/fd/NN
References: <87pnv8kke8.fsf@thinkpad.rath.org>
        <CAJfpegs6knndH=K85hHWABCd4XvKLV9X8DYJoFaqd56XArz6Ew@mail.gmail.com>
Date: Wed, 14 Nov 2018 12:10:20 +0000
In-Reply-To: <CAJfpegs6knndH=K85hHWABCd4XvKLV9X8DYJoFaqd56XArz6Ew@mail.gmail.com>
        (Miklos Szeredi's message of "Wed, 14 Nov 2018 12:57:20 +0100")
Message-ID: <87muqblv0z.fsf@thinkpad.rath.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Nov 14 2018, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Wed, Nov 14, 2018 at 11:45 AM, Nikolaus Rath <Nikolaus@rath.org> wrote:
>> Hi,
>>
>> If I understand Documentation/filesystems/path-lookup.md correctly, then
>> the "symlinks" in /proc/self/fd/NN are not true symlinks but just
>> presented as such to userspace. Does this mean that I can access (e.g.,
>> open(), setxattr(), or chmod()) these files without the possibility of
>> race conditions? I.e., there is no way for someone to rename the target
>> after the kernel has "looked up" the target but before the operation is
>> applied?
>
> Exactly.   The only limitation is that if the target is a symlink (fd
> opened with O_PATH) then the neither the symlink following, nor the
> non-following variants will do the right thing (see *xattr ops in
> passthrough_ll for example).

A workaround for that case would be to use readlink() and then act on
that without eg lgetxattr. That would introduce a race condition, but it
would work where that's not a concern, right?

That said, I also noticed the following code to handle utimens for symlinks:

res =3D utimensat(inode->fd, "", tv,
		AT_EMPTY_PATH | AT_SYMLINK_NOFOLLOW);
if (res =3D=3D -1 && errno =3D=3D EINVAL) {
	/* Sorry, no race free way to set times on symlink. */
	errno =3D EPERM;
}

So it looks as it at least utimensat() does the right thing under at
least some conditions...?


>> Secondly, under which conditions can I open the files in /proc? Does
>> this still work if the destination file has been unlinked?
>
> Yes.
>
>> Does it
>> always follow renames? What if I mounted something over the destination?
>
> It works in all those cases.

Did you mean it *always* works, or it works in the cases I listed but
there are other cases where it can fail?


Thanks!
-Nikolaus

--=20
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             =C2=BBTime flies like an arrow, fruit flies like a Banana.=C2=
=AB