Well, I don't really can test it either, so it would have to be tested
by others.
I don't really understand, how this race between AIO and setresuid would affect
the result of setresuid.
Seems it's fix the result of the (Asynchronous IO), not of setresuid.
But I have an even much bigger problem with this.
My understanding of the problem (which could well be wrong), is that Linux have
effective user ID by thread,
rather than by process (this is one of the big guess I make that are often
wrong).
But POSIX works with uid on process rather than threads (yes, an other guess).
So, glibc guys, think that they should change effective uid of other threads of
the process to respect the POSIX standard.
Which does make sense to me (even if it may cause problems like race condition
with AIO, and maybe other stuff).
Now, my really big problem with all this, is that glibc seems to have made a
big error.
They seems to think that setresuid is a syscall in the POSIX standards, and
setreuid is not.
After all, they seems to have made setresuid ('being smart' about changing
other threads of the process).
But it is reverse, as far as I know: setresuid is not part of any POSIX
standard, but setreuid is.
Need to find back the pdf where I have read that.
Now, what would seems like a better patch for me, would be to simply make a
loop to retry 3 to 5 times,
the setresuid or setreuid, when the result is EAGAIN, which does means after
all, "can not do your requested
operation now, please try again".
** Also affects: glibc (Ubuntu)
Importance: Undecided
Status: New
--
Samba crashes repeatedly to assert_uid
https://bugs.launchpad.net/bugs/216358
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in ubuntu.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
