On Wed, Nov 14, 2018 at 1:29 PM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote:
> [Trimming Cc since this gets fuse specific]
>
> On Nov 14 2018, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>> On Wed, Nov 14, 2018 at 1:10 PM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote:
>>> On Nov 14 2018, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>>>> On Wed, Nov 14, 2018 at 11:45 AM, Nikolaus Rath <Nikolaus@xxxxxxxx> 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...
That wouldn't help the symlink case though.
I'm not saying passthrough_ll coudln't be improved, in fact it
probably will need to be, since it's the base of the soon to be
announced virtio-fs server...
Thanks,
Miklos
