setresuid, setreuid AIO, bug? where?

[Paul Dufresne]

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 <scott at 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
> scott at canonical.com
>