Thread (88 messages) 88 messages, 14 authors, 2020-08-21

Re: file metadata via fs API (was: [GIT PULL] Filesystem Information)

From: Andy Lutomirski <luto@kernel.org>
Date: 2020-08-11 21:18:05
Also in: linux-api, linux-fsdevel, lkml

On Tue, Aug 11, 2020 at 1:56 PM Miklos Szeredi [off-list ref] wrote:
On Tue, Aug 11, 2020 at 10:37 PM Jann Horn [off-list ref] wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help