All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: futimens use of utimensat does not support O_PATH fds
Date: Fri, 8 Aug 2025 12:01:56 -0700	[thread overview]
Message-ID: <aJZJpIEJB2R0x-Hh@localhost> (raw)
In-Reply-To: <20250808-ziert-erfanden-15e6d972ae43@brauner>

On Fri, Aug 08, 2025 at 03:22:58PM +0200, Christian Brauner wrote:
> On Thu, Aug 07, 2025 at 02:01:15PM -0700, Josh Triplett wrote:
> > I just discovered that opening a file with O_PATH gives an fd that works
> > with
> > 
> > utimensat(fd, "", times, O_EMPTY_PATH)
> > 
> > but does *not* work with what futimens calls, which is:
> > 
> > utimensat(fd, NULL, times, 0)
> 
> It's in line with what we do for fchownat() and fchmodat2() iirc.
> O_PATH as today is a broken concept imho. O_PATH file descriptors
> should've never have gained the ability to meaningfully alter state. I
> think it's broken that they can be used to change ownership or mode and
> similar.

In the absence of having O_PATH file descriptors, what would be the way
to modify the properties of a symlink using race-free
file-descriptor-based calls rather than filenames? AFAICT, there's no
way to get a file descriptor corresponding to a symbolic link without
using `O_PATH | O_NOFOLLOW`.

It makes sense that a file descriptor for a symbolic link would be able
to do inode operations but not file operations.

  reply	other threads:[~2025-08-08 19:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-07 21:01 futimens use of utimensat does not support O_PATH fds Josh Triplett
2025-08-07 21:51 ` Aleksa Sarai
2025-08-08  2:16   ` Josh Triplett
2025-08-08 13:22 ` Christian Brauner
2025-08-08 19:01   ` Josh Triplett [this message]
2025-08-10  4:44     ` Aleksa Sarai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aJZJpIEJB2R0x-Hh@localhost \
    --to=josh@joshtriplett.org \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.