Conversation

Notices

1. Embed this notice
   Rich Felker (dalias@hachyderm.io)'s status on Thursday, 29-May-2025 01:59:08 JST Rich Felker

   @brynet The feature sounds good, altho as always I think it'd be better if folks proposing new stuff like that reach out to look for consensus with other implementors before committing to an interface & contract. I was more talking about the attitude that openat isn't useful because it's not a security boundary.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 29-May-2025 02:29:03 JST Rich Felker

     in reply to

     • Can Acar

     @canacar @brynet I was addressing the quoted text:

     "openat(2) is mostly useless, sadly"

     and in the body:

     "The family of system calls related to openat(2) are mostly useless in
     practice, rarely used. When they are used it is often ineffectively or
     even with performance-reducing results."

     The purpose of the at-family functions is to make it so that you don't have to manipulat process-global working directory, which is non-thread-safe, in order to process relative pathnames or traverse nasty trees exceeding PATH_MAX depth. It's not for performance or security but for correctness.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Can Acar (canacar@ioc.exchange)'s status on Thursday, 29-May-2025 02:29:04 JST Can Acar

     in reply to

     @dalias the email already points out that openat() was not designed for security but both Linux and FreeBSD made changes to make it so: "... their strategy was to add an additional flag which didn't allow upwards traversal. I think that misses the point, and have a different proposal."
     @brynet

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 29-May-2025 07:12:30 JST Rich Felker

     in reply to

     • Ed Maste

     @emaste @brynet https://www.openwall.com/lists/libc-coord/

   • Embed this notice
     Ed Maste (emaste@mastodon.social)'s status on Thursday, 29-May-2025 07:12:31 JST Ed Maste

     in reply to

     @dalias @brynet Can you think of a good place for that collaboration to happen? Some exist for e.g. libc functionality, but I'm not sure where OpenBSD folks should reach out to look for consensus.

     FreeBSD folks already have a similar change in progress, but without a user-facing interface. Fediverse posts might prompt BSD collaboration here. I don't know where a discussion with Linux kernel folks would happen.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 29-May-2025 07:15:14 JST Rich Felker

     in reply to

     • Ed Maste

     @emaste @brynet Probably not, but I don't think "kernel folks" is the main important group. It's a matter of interfaces for use by applications. But we probably should try to get more kernel folks participating there, especially since "design by kernel folks" is a big problem with new APIs on Linux too...

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Ed Maste (emaste@mastodon.social)'s status on Thursday, 29-May-2025 07:15:15 JST Ed Maste

     in reply to

     @dalias @brynet There's a reasonable collection of kernel folks there?