On Fri, Jul 30, 2021 at 12:25 PM Ralph Boehme <slow@xxxxxxxxx> 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@xxxxxxxxxxxxxx/
[2] https://lore.kernel.org/linux-fsdevel/20200916002335.GQ3265@xxxxxxxxxxxxxxxxxxxxx/
