Re: Allowed operations on O_PATH handles

[Amir Goldstein <amir73il@gmail.com>]

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/