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