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
signature.asc
Description: This is a digitally signed message part
-- 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
