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:
>>> 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?
Right, readlink + op would work most of the time, but in the corner
cases you describe (deleted, race with rename, overmount of ancestor)
it would not, and the result would be arbitrary, failure is not
guaranteed.
>
> 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
>
>
>>> 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?
It always works if symlink following is enabled, because internally it
just copies the logical path that the open file refers to.
Thanks,
Miklos
