Re: Behaviour of /proc/self/fd/NN

[Nikolaus Rath <Nikolaus@rath.org>]

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:
>> 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.«