[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Jul 2011 19:51:11 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Daily cluts reports - numeric, setuid, and mid-term
evaluation
On Sat, Jul 16, 2011 at 12:47:56AM +0200, Luka Marčetić wrote:
> * Fixing setuid.c, which should do its job of testing
> setuid/getuid in a threaded environment now - those who are
> following are probably interested in the results: The test indeed
> reports failure on certain libc's, but before I can say with
> confidence that the test is correct, I'm going to need a second pair
> of eyes, so if you're willing to review it please do fetch the file.
> More about this in #musl.
I'm glad you were able to get results! In the current form, the test
isn't checking exactly what it's supposed to, but it's very close.
What you're testing is for mismatch in the getuid() results for the
first- and last-created threads. There are a couple problems with this
but they're easily fixed:
Issue 1: The first- and last-created threads are not necessarily the
first and last threads to make the syscall. By checking that *all*
threads have the same result, rather than just the first and last, you
could find failures with a lot fewer tries.
Issue 2: While I believe it's "A Bad Thing" and non-conformant for
getuid() to ever return different results in different threads, the
*dangerous* case is when setuid() reported success but didn't actually
succeed in all threads. I would ignore the result (or only print a
warning, and continue searching for a more serious failure) when
setuid() returns -1. I sloppily made this change and no longer saw any
failures in musl, though it seems like it might be deadlocking
sometime... Haven't tested the change with glibc but I expect to still
see failures.
Rich
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.
