From: Nikolaus Rath <Nikolaus@rath.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Behaviour of /proc/self/fd/NN
Date: Wed, 14 Nov 2018 12:29:06 +0000 [thread overview]
Message-ID: <87k1lflu5p.fsf@thinkpad.rath.org> (raw)
In-Reply-To: <CAJfpegsohJg+d7X7Qbusnz4=N+0yfKxg30UN11jhGVTZ6JSwmg@mail.gmail.com> (Miklos Szeredi's message of "Wed, 14 Nov 2018 13:20:47 +0100")
[Trimming Cc since this gets fuse specific]
On Nov 14 2018, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Wed, Nov 14, 2018 at 1:10 PM, Nikolaus Rath <Nikolaus@rath.org> wrote:
>> 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:
>>>> 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).
>>
>> That said, I also noticed the following code to handle utimens for symlinks:
>>
>> res = utimensat(inode->fd, "", tv,
>> AT_EMPTY_PATH | AT_SYMLINK_NOFOLLOW);
>> if (res == -1 && errno == EINVAL) {
>> /* Sorry, no race free way to set times on symlink. */
>> errno = 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=linux-kernel&m=154158217810354&w=2
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
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
next prev parent reply other threads:[~2018-11-14 22:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-14 10:45 Behaviour of /proc/self/fd/NN Nikolaus Rath
2018-11-14 11:57 ` Miklos Szeredi
2018-11-14 12:10 ` Nikolaus Rath
2018-11-14 12:20 ` Miklos Szeredi
2018-11-14 12:29 ` Nikolaus Rath [this message]
2018-11-14 12:33 ` Miklos Szeredi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k1lflu5p.fsf@thinkpad.rath.org \
--to=nikolaus@rath.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.