Behaviour of /proc/self/fd/NN

Behaviour of /proc/self/fd/NN

[Nikolaus Rath]

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?

Secondly, under which conditions can I open the files in /proc? Does
this still work if the destination file has been unlinked? Does it
always follow renames? What if I mounted something over the destination?

(Background: I'm trying to ascertain how well a true bind mount can be
emulated by a passthrough FUSE filesystem).

Best,
-Nikolaus
-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

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

[Miklos Szeredi]

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).

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

Thanks,
Miklos

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

[Nikolaus Rath]

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

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

[Miklos Szeredi]

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

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

[Nikolaus Rath]

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

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

[Miklos Szeredi]

On Wed, Nov 14, 2018 at 1:29 PM, Nikolaus Rath <Nikolaus@rath.org> wrote:
> [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...

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