Allowed operations on O_PATH handles

Allowed operations on O_PATH handles

[Ralph Boehme]

[-- Attachment #1.1: Type: text/plain, Size: 998 bytes --]

Hi!

A recent commit 44a3b87444058b2cb055092cdebc63858707bf66 allows 
utimensat() to be called on O_PATH opened handles.

If utimensat() is allowed, why isn't fchmod()? What's the high level 
rationale here that I'm missing? Why is this not documented in man openat.2?

 From man openat.2

   O_PATH (since Linux 2.6.39)

     Obtain a file descriptor that can be used for two purposes:
     to indicate a location in the filesystem tree and to perform
     operations that act purely at the file descriptor level. The
     file itself is not opened, and other file operations (e.g.,
     read(2),  write(2),   fchmod(2),   fchown(2),   fgetxattr(2),
     ioctl(2), mmap(2)) fail with the error EBADF.
     ...

My understanding of which operations are allowed on file handles opened 
with O_PATH was that generally modifying operations would not be 
allowed, but only read access to inode data.

Can someone please help me to make sense of this?

Thanks a lot!
-slow


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: Allowed operations on O_PATH handles

[Amir Goldstein]

On Fri, Jul 30, 2021 at 12:25 PM Ralph Boehme <slow@samba.org> wrote:
>
> Hi!
>

Hi Ralph!

> A recent commit 44a3b87444058b2cb055092cdebc63858707bf66 allows
> utimensat() to be called on O_PATH opened handles.
>
> If utimensat() is allowed, why isn't fchmod()? What's the high level
> rationale here that I'm missing? Why is this not documented in man openat.2?
>

As you noticed, there is no uniformity among the various filesystem syscalls,
but there are some common guidelines.

1. O_PATH fds are normally provided as the dirfd argument to XXXat()
    calls (such as utimensat()).
2. When the syscall supports empty name with dirfd to represent the
    O_PATH fd object itself, an explicit AT_EMPTY_PATH is required

So the commit above simply brings utimensat() up to standards.

>  From man openat.2
>
>    O_PATH (since Linux 2.6.39)
>
>      Obtain a file descriptor that can be used for two purposes:
>      to indicate a location in the filesystem tree and to perform
>      operations that act purely at the file descriptor level. The
>      file itself is not opened, and other file operations (e.g.,
>      read(2),  write(2),   fchmod(2),   fchown(2),   fgetxattr(2),
>      ioctl(2), mmap(2)) fail with the error EBADF.
>      ...
>
> My understanding of which operations are allowed on file handles opened
> with O_PATH was that generally modifying operations would not be
> allowed, but only read access to inode data.
>

I think the rationale is that they are allowed when a user explicitly
requests to use them via a new XXXat(..., AT_EMPTY_PATH) API.

write(),read(),mmap() are different because they access file data,
so it is required that the file is "really open".

Letting fgetxattr() accept an O_PATH was actually suggested [1],
but the author (Miklos) dropped it shortly after, because there is
already a safe API to achieve the same goal using magic /proc
symlink (see details in [1]).

If you need to operate on a (real) symlink target and you have an
O_PATH to the (real) symlink, you will need to work a bit harder.
Adding AT_EMPTY_PATH to fchmodat() and friends could make
this task easier and I don't think there would be an objection to do
that, just someone needs to drive the work...

fchmodat() specifically is a bit broken and an attempt to introduce
fchmodat2() was attempted [2], but did not go through.

> Can someone please help me to make sense of this?
>

Does that answer your question or do you have other needs
that the current API cannot provide?

Thanks,
Amir.

[1] https://lore.kernel.org/linux-fsdevel/CAOssrKeV7g0wPg4ozspG4R7a+5qARqWdG+GxWtXB-MCfbVM=9A@mail.gmail.com/
[2] https://lore.kernel.org/linux-fsdevel/20200916002335.GQ3265@brightrain.aerifal.cx/

Re: Allowed operations on O_PATH handles

[Ralph Boehme]

[-- Attachment #1.1: Type: text/plain, Size: 2537 bytes --]

Hi Amir!

Am 30.07.21 um 18:57 schrieb Amir Goldstein:
> On Fri, Jul 30, 2021 at 12:25 PM Ralph Boehme <slow@samba.org> wrote:
>> A recent commit 44a3b87444058b2cb055092cdebc63858707bf66 allows
>> utimensat() to be called on O_PATH opened handles.
>>
>> If utimensat() is allowed, why isn't fchmod()? What's the high level
>> rationale here that I'm missing? Why is this not documented in man openat.2?
>>
> 
> As you noticed, there is no uniformity among the various filesystem syscalls,
> but there are some common guidelines.
> 
> 1. O_PATH fds are normally provided as the dirfd argument to XXXat()
>      calls (such as utimensat()).

obvious.

> 2. When the syscall supports empty name with dirfd to represent the
>      O_PATH fd object itself, an explicit AT_EMPTY_PATH is required

If this is wanted, this is not documented in the manpage. Lacking any 
other reference then reading kernel sources, I would say this is a bit 
of a challenge for userspace developers. :)

>>   From man openat.2
>>
>>     O_PATH (since Linux 2.6.39)
>>
>>       Obtain a file descriptor that can be used for two purposes:
>>       to indicate a location in the filesystem tree and to perform
>>       operations that act purely at the file descriptor level. The
>>       file itself is not opened, and other file operations (e.g.,
>>       read(2),  write(2),   fchmod(2),   fchown(2),   fgetxattr(2),
>>       ioctl(2), mmap(2)) fail with the error EBADF.
>>       ...
>>
>> My understanding of which operations are allowed on file handles opened
>> with O_PATH was that generally modifying operations would not be
>> allowed, but only read access to inode data.
>>
> 
> I think the rationale is that they are allowed when a user explicitly
> requests to use them via a new XXXat(..., AT_EMPTY_PATH) API.
> 
> write(),read(),mmap() are different because they access file data,
> so it is required that the file is "really open".
> 
> Letting fgetxattr() accept an O_PATH was actually suggested [1],
> but the author (Miklos) dropped it shortly after, because there is
> already a safe API to achieve the same goal using magic /proc
> symlink (see details in [1]).

Yep, this is what we use in Samba.

>> Can someone please help me to make sense of this?
>>
> 
> Does that answer your question or do you have other needs
> that the current API cannot provide?

Thanks for providing some pointers. The basic problem I see is the lack 
of documentation of the API.

Thanks!
-slow


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]