On Wed, Feb 11, 2015 at 01:42:13AM -0600, Rob Landley wrote: > On 02/10/2015 06:37 PM, Rich Felker wrote: > > On Tue, Feb 10, 2015 at 01:47:01AM -0600, Rob Landley wrote: > >> rapidly respond to arbitrary file creation ala inotify, we're toast. So > >> the attack vector would be... saturating the namespace with symlinks? > >> (It'd be really nice if O_NOFOLLOW was more generally applicable, but > >> we've had that fight. Also the posix function is specified NOT to use > >> O_NOFOLLOW. So let's assume symlink attacks are doable here and somehow > >> useful even with O_EXCL, creating the file at a known location you can > >> spin to check for or something.) > > > > Which POSIX function is specified not to use O_NOFOLLOW? > > faccessat() for starters. :)
I realize you may be joking, so apologies in advance if I'm misinterpreting this. There's a big difference between being "specified not to use" and "not specified to support". There's also a difference between O_NOFOLLOW (whose suppose is mandatory) and AT_SYMLINK_NOFOLLOW (which was intended for different operations and not specified for faccessat). But most importantly, these functions (access and faccessat) have no place anywhere near tmpfile handling code. They are exactly the kind of broken design (TOCTOU races) that created tmp vulns in the first place. > Makes me a touch reluctant to give it much credence anywhere else after > that mess. It's an imaginary mess. These functions are useless. As useless as gets() if not moreso (since their wrongness is more subtle). Please, just lay them to rest. Rich _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
