All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: futimens use of utimensat does not support O_PATH fds
Date: Thu, 7 Aug 2025 19:16:38 -0700	[thread overview]
Message-ID: <aJVeBt2FBl_cQOIO@localhost> (raw)
In-Reply-To: <2025-08-07.1754602716-spare-cyan-roughage-volcano-lW6q7A@cyphar.com>

On Fri, Aug 08, 2025 at 07:51:26AM +1000, Aleksa Sarai wrote:
> On 2025-08-07, Josh Triplett <josh@joshtriplett.org> wrote:
> > I just discovered that opening a file with O_PATH gives an fd that works
> > with
> > 
> > utimensat(fd, "", times, O_EMPTY_PATH)
> 
> I guess you mean AT_EMPTY_PATH? We don't have O_EMPTY_PATH on Linux
> (yet, at least...).

Yes, that was a typo.

> The set of things that are and are not allowed on O_PATH file
> descriptors is a bit of a hodge-podge these days. Originally the
> intention was for all of these things to be blocked by O_PATH (kind of
> like O_SEARCH on other *nix systems) but the existence of AT_EMPTY_PATH
> (and /proc/self/fd/... hackery) slowly led more and more things to be
> allowed.

I do appreciate that. In large part, I'm trying to figure out if it
would be reasonable for this specific case to work, based on the premise
that it doesn't add any new capability, just makes an existing
capability available more consistently.

Having that would make it easier to write portable code with *fewer*
branches for Linux. It'd still be necessary to *open* files with the
Linux-specific O_PATH, but generic library routines that operate on open
files wouldn't have to change.

- Josh Triplett

  reply	other threads:[~2025-08-08  2:16 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 [this message]
2025-08-08 13:22 ` Christian Brauner
2025-08-08 19:01   ` Josh Triplett
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=aJVeBt2FBl_cQOIO@localhost \
    --to=josh@joshtriplett.org \
    --cc=cyphar@cyphar.com \
    --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.