Re: [Toybox] [PATCH] mktemp fixes
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. :) Makes me a touch reluctant to give it much credence anywhere else after that mess. Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] mktemp fixes
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 XX 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
Re: [Toybox] Regarding test.sh
On 02/03/2015 11:14 PM, Yeongdeok Suh wrote: Hello, I usually use 'scripts/test.sh' scrips for testing ARM based boards. But Toybox test script does compile and running at the same time, so it's hard to compile and execute testsuite independently in cross compile environment, On the other hand, busybox test script works that separately. Does it have any reason? If you set TEST_HOST=1 it will test the commands in the existing $PATH. I'm considering add options to 'scripts/test.sh' (compile-only / run-testsuite-only options) You can compile with scripts/single.sh commandname, so you can do something like: scripts/single.sh command mkdir sub mv command sub PATH=$PWD/sub:$PATH TEST_HOST=1 scripts/test.sh command I thought this was documented somewhere... yes, in code.html. (Alas, not very prominently, but it is there. Under Directory scripts/, see http://landley.net/toybox/code.html#toys and yes I need a better anchor tag for that.) And does Android use this script for testing? Elliott mentioned that he does a lot of testing by hand. I need to improve the infrastructure to meet their needs better. Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
