On Tue, Feb 10, 2015 at 01:47:01AM -0600, Rob Landley wrote: > > sort-of speaking of which... i didn't include this before since it > > wasn't really a bug fix but do you think we should use more > > randomness? 6 Xes is the minimum you're allowed to pass to the C > > library, and the desktop mktemp(1) defaults to 10. > > I don't have a strong opinion either way? > > Backing up: the man page for mkdtemp/mkstemp says "the last six > characters of template must be XXXXXX" and the posix spec backs that up, > meaning the libc functions seem hardwired to 6 characters.
POSIX is allowing >6 as an extension, but it's not terribly useful. > If you can predict the random digits, we're toast anyway. If you can For DoS only. The only times anything worse happens is when you already have a fatal programming error with regards to file creation/opening. These were problems that were solved 25+ years ago; the only reason they (/tmp vulns) keep appearing is because people fail to make correct use of the tools they already have like O_EXCL. > 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? Rich _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
