Date: Sat, 09 Jul 2011 17:30:42 +0200 From: Luka Marčetić <paxcoder@...il.com> To: musl@...ts.openwall.com Subject: Re: Daily reports: Friday On 07/09/2011 01:53 PM, Solar Designer wrote: > OK, let's wait for Rich's comments on this. BTW, chances are that the > RLIMIT_NPROC check on setuid(2) and friends will be removed from future > kernels: http://www.openwall.com/lists/kernel-hardening/2011/07/06/8 > > I understand that Rich's proposed tests are about the libc wrapper > functions that are thread-aware rather than about syscalls, yet I felt > the above was relevant to the tests. Ok. > use tricks like grepping function prototypes for size_t inside > the argument list. I meant more like specific phrases in the description of the function, though combining size_t with what char * might be useful too. > There's some overlap with 1 ("String operations testing"), though. > Maybe for string functions, this check should be one of those performed > as part of those tests, whereas 6 ("Functions which return strings in > caller-provided buffers") should focus on other functions - things such > as getcwd(). Or maybe not. Just a thought. Now that you mentioned it, indeed string.c ("String operations testing") should perhaps fully address strn* functions. It makes sense. I'll probably put the strn* functions (and the mem* ones) there then, and try to find those getcwd()-like for the current task. Before I do the former though, I'll have to redesign string.c to be more flexible - something along the lines of what I've been doing with the new "test collections (or as much as C premits). Otherwise, it would take ages to write tests the way they were written so far (especially knowing string.c's scope, and the sheer number of functions it needs to test). Descriptiveness of errors may suffer a bit, but I think it's the best thing to do. >> my plan is finishing 6 first (right now it's called strn.c), >> then moving on to 8. > Sounds fine to me. Why not 7 ("Functions which manipulate temp copies > of an argument string"), though? I hoped to do 8 (Threaded setuid race conditions) because I wanted to make it a bit more interesting for me - simply as a change from what I've been doing in numeric.c - but also to learn setuid (I've never used it). Under the circumstances though, I am instead doing a similar thing in strn.c (6). If I finish that before Rich gets back to me, I may move on to nr. 7 (Functions which manipulate temp copies of an argument string), although I don't consider 6 or 7 to be demanding tasks (perhaps only timely, because there is plenty of stuff to test). >> P.S. This may be a double-post. If it is, my apologies. > I got only one copy of it. I find the ever-changing Subjects with > preserved Re: on them weird, though. Oh, ok. I should've ommitted the "-cont" I agree. However, being Re:'s to each other, I hope they still fall under the same thread. As an orientation, I may use the latest commits eg "strn.c + comon/String.c" as part of the Subject, or I may drop differentiation completely and just have us rely on time stamps. In the end, there's always this to monitor specific commits: https://github.com/lmarcetic/cluts/commits/master Luka.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.