Le mercredi 29 avril 2015 à 13:58 -0500, Rob Landley a écrit : > > On 04/22/2015 11:45 AM, José Bollo wrote: (snip)
> > 2. Why the API of dirtree doesn't have a scratch buffer of at most > > PATH_MAX to provide the same behaviour? Well it would be easier than > > changing ABI of the kernel. Having a scratch buffer might be easy. The > > same function, dirtree_path, could return always the same scratch > > buffer. If you need it for a long period or because of it can be > > overwritten, just strdup it and later free it. > > The reason it doesn't is PATH_MAX went away years ago. It never made > sense: you can "mkdir -p one/two/three/four/five", cd into that, and > them "mv ~/equally/long/tree .", and thus no matter what your "maximum" > path value is you can always construct one in the filesystem that's > longer, and then the tools just have to cope. (Posix specifically > requires rm to deal with arbitrary depth, which means even my "keep an > open filehandle per level" logic has to go; I have a design to fix that > but don't think I've implemented it yet.) It is a good reason. > That's why all the modern apis work based on openat() and friends. The > alternative is constantly changing cwd, which gets racy and evil even > _without_ threads. ok, it makes sense. (snip) > In 2.6.39 the kernel guys added the O_PATH flag: > > http://man7.org/linux/man-pages/man2/open.2.html > > Which allows you to open a file without read permissions. (O_RDONLY is > zero so you can't _not_ specify "I would like read permission on this > file". So they had to add O_PATH to say "switch off the O_RDONLY bit > even though there isn't one".) > > The point of this would be to let you open a chmod 000 file via openat() > and then use functions like fgetxattr() on it. (And this eliminates some > races because you can fstat() the filehandle and go "yup, this is a > directory" before proceeding.) > > I'm leaning towards rewriting your ls patch to use openat() with O_PATH > and use that to avoid allocating, traversing, and freeing full paths > from cwd for every file. Agreed, also leaning toward that path. > Of course I dunno if your security infrastructure is going to veto the > open anyway. Still can't test it... The issue is maybe not related to security. The reason is that both lgetxattr and open(READ|NOFOLLOW|NOATIME) will fail if security forbids the read. The consistency of access time of the file can be managed with NOATIME. Best regards José > > Rob > _______________________________________________ > Toybox mailing list > [email protected] > http://lists.landley.net/listinfo.cgi/toybox-landley.net _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
