From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com ([66.111.4.29]:43299 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727722AbeKNWcM (ORCPT ); Wed, 14 Nov 2018 17:32:12 -0500 From: Nikolaus Rath To: Miklos Szeredi Cc: linux-fsdevel Subject: Re: Behaviour of /proc/self/fd/NN References: <87pnv8kke8.fsf@thinkpad.rath.org> <87muqblv0z.fsf@thinkpad.rath.org> Date: Wed, 14 Nov 2018 12:29:06 +0000 In-Reply-To: (Miklos Szeredi's message of "Wed, 14 Nov 2018 13:20:47 +0100") Message-ID: <87k1lflu5p.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: [Trimming Cc since this gets fuse specific] On Nov 14 2018, Miklos Szeredi wrote: > On Wed, Nov 14, 2018 at 1:10 PM, Nikolaus Rath wrote: >> On Nov 14 2018, Miklos Szeredi wrote: >>> On Wed, Nov 14, 2018 at 11:45 AM, Nikolaus Rath wro= te: >>>> If I understand Documentation/filesystems/path-lookup.md correctly, th= en >>>> 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). >> >> That said, I also noticed the following code to handle utimens for symli= nks: >> >> 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...? > > Not yet upstream. Here's the patch: > > https://marc.info/?l=3Dlinux-kernel&m=3D154158217810354&w=3D2 Thanks! Is there any reason that we don't try to open *files* as O_RDWR or such and only fall back to O_PATH if that doesn't work? That should enable us to use fsetxattr et all in many cases, right? The kernel already does permission checking (so that's not a concern), and we should never need a dirfd for a file... Best, -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