On Nov 14 2018, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Wed, Nov 14, 2018 at 11:45 AM, Nikolaus Rath <Nikolaus@xxxxxxxx> 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 = 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...?
>> 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
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
