Hi Amir! Am 30.07.21 um 18:57 schrieb Amir Goldstein:
On Fri, Jul 30, 2021 at 12:25 PM Ralph Boehme <slow@xxxxxxxxx> 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:
OpenPGP_signature
Description: OpenPGP digital signature
