All of lore.kernel.org
 help / color / mirror / Atom feed
* Allowed operations on O_PATH handles
@ 2021-07-30  9:22 Ralph Boehme
  2021-07-30 16:57 ` Amir Goldstein
  0 siblings, 1 reply; 3+ messages in thread
From: Ralph Boehme @ 2021-07-30  9:22 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: Miklos Szeredi, Christoph Hellwig


[-- 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 --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Allowed operations on O_PATH handles
  2021-07-30  9:22 Allowed operations on O_PATH handles Ralph Boehme
@ 2021-07-30 16:57 ` Amir Goldstein
  2021-08-04 14:20   ` Ralph Boehme
  0 siblings, 1 reply; 3+ messages in thread
From: Amir Goldstein @ 2021-07-30 16:57 UTC (permalink / raw)
  To: Ralph Boehme
  Cc: linux-fsdevel, Miklos Szeredi, Christoph Hellwig, Aleksa Sarai,
	Rich Felker

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/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Allowed operations on O_PATH handles
  2021-07-30 16:57 ` Amir Goldstein
@ 2021-08-04 14:20   ` Ralph Boehme
  0 siblings, 0 replies; 3+ messages in thread
From: Ralph Boehme @ 2021-08-04 14:20 UTC (permalink / raw)
  To: Amir Goldstein
  Cc: linux-fsdevel, Miklos Szeredi, Christoph Hellwig, Aleksa Sarai,
	Rich Felker


[-- 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 --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-08-04 14:20 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-30  9:22 Allowed operations on O_PATH handles Ralph Boehme
2021-07-30 16:57 ` Amir Goldstein
2021-08-04 14:20   ` Ralph Boehme

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.