setresuid, setreuid AIO, bug? where?

Scott James Remnant scott at canonical.com
Mon Mar 23 13:20:40 UTC 2009


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20090323/3e9bafaa/attachment.pgp>


More information about the Ubuntu-devel-discuss mailing list