On Tue, Aug 11, 2020 at 1:56 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Tue, Aug 11, 2020 at 10:37 PM Jann Horn <jannh@xxxxxxxxxx> wrote: > > If you change the semantics of path strings, you'd have to be > > confident that the new semantics fit nicely with all the path > > validation routines that exist scattered across userspace, and don't > > expose new interfaces through file server software and setuid binaries > > and so on. > > So that's where O_ALT comes in. If the application is consenting, > then that should prevent exploits. Or? We're going to be at risk from libraries that want to use the new O_ALT mechanism but are invoked by old code that passes traditional Linux paths. Each library will have to sanitize paths, and some will screw it up. I much prefer Linus' variant where the final part of the extended path is passed as a separate parameter.
