|
Message-ID: <20110715235111.GR16618@brightrain.aerifal.cx> 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.