Re: Daily reports: Friday

["Luka Marčetić" <paxcoder@gmail.com>]

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.