Scott said: The Samba bug appears to be a race condition between AIO and setresuid()
Yep, but I tend to believe that this race condition is directly inside the kernel. My reasoning is that the http://samba.org/~tridge/junkcode/aio_uid.c does seems to be all inside a simple process and not be using pthreads. My understanding is that only when you use pthreads, should setreuid become non-atomic (because then it has to iterate the thread group in user-space, like you said). But aio_uid seems to bug when using setresuid, not when using setreuid. Which is the reverse than what I could expect. 2009/3/23, Scott James Remnant <sc...@canonical.com>: > On Sun, 2009-03-22 at 22:58 -0400, Paul Dufresne wrote: > >> But the comment from a glibc developer: >> https://bugzilla.redhat.com/show_bug.cgi?id=459901#c1 >> made me thinks: Hey, don't they know at glibc that this is setreuid >> that is in Posix standard, >> not setresuid!? >> > Unless I'm mistaken, you've made the same confusion in your mail here? > > The Samba bug appears to be a race condition between AIO and setresuid() > > setresuid() is a Linux-specific system call added in Linux 2.1.44, and > glibc 2.3.2; while it's also apparently implemented by HP-UX and some > of the BSDs, there's never any guarantee that the implementations are > entirely compatible. > > > On the other hand, you seem to have started to look for the > implementation of setresuid() and then segued into the implementation of > setreuid(). > > setreuid() is specified by POSIX.1-2001 > > > Now, you quote Jakub Jeliner in a Red Hat bug report saying: > > It is not about glibc trying to be smart, it is simply that POSIX > requires the call to affect the whole process, and kernel folks > refusing to implement that behavior in the kernel. > > What he's basically saying here is that POSIX requires that "the current > process" includes all threads; this is likely specified for setreuid() > so they match the behaviour for setresuid(). > > As you may know, the Linux kernel actually implements threads as > separate processes! There's no "thread" primitive in the kernel. So at > a first pass, syscalls would only affect the calling _thread_, not the > calling process. > > He says that the Kernel developers refuse to hide this behaviour from > the system call layer, and instead you have to deal with it in > userspace. This has actually been an advantage in the past, it's > allowed Linux to change threading libraries and models - so it's > arguable that it's been a good thing. > > So in userspace, in order to implement the POSIX-specified behaviour of > "calling process", you have to iterate the thread group. This makes it > non-atomic. > > Scott > -- > Scott James Remnant > sc...@canonical.com > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
