Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 11 Aug 2020 14:17:46 -0700 | Subject | Re: file metadata via fs API (was: [GIT PULL] Filesystem Information) |
| |
On Tue, Aug 11, 2020 at 1:56 PM Miklos Szeredi <miklos@szeredi.hu> wrote: > > On Tue, Aug 11, 2020 at 10:37 PM Jann Horn <jannh@google.com> 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.
| |