[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E187422.6070601@gmail.com>
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.
