Created attachment 325225 [details] c-code to show the problem. Description of problem: When using seteuid or setegid in a thread, tgkill is issued with SIGRT_1, what makes certain software constantly talk, that an unknown signal has been caught. Version-Release number of selected component (if applicable): glibc-2.5-24 How reproducible: compile the attached example and run in strace Steps to Reproduce: 1. gcc seteuid.c -o seteuid -lpthread -g 2. strace ./seteuid 3. See the strace output: [pid 23370] futex(0x420719d0, FUTEX_WAIT, 23371, NULL <unfinished ...> [pid 23371] set_robust_list(0x420719e0, 0x18) = 0 [pid 23371] tgkill(23370, 23370, SIGRT_1) = 0 [pid 23370] <... futex resumed> ) = -1 EINTR (Interrupted system call) [pid 23371] futex(0x42071100, FUTEX_WAIT, 1, NULL <unfinished ...> [pid 23370] --- SIGRT_1 (Unknown signal 33) @ 0 (0) --- [pid 23370] setresuid(-1, 35344, -1) = -1 EPERM (Operation not permitted) [pid 23370] futex(0x42071100, FUTEX_WAKE, 1 <unfinished ...> Actual results: see above. No problem with this simple program, but with software from other vendor, e.g. eDirectory from Novell. Expected results: No error Additional info:
That is Novell eDirectory bug then. Programs are only allowed to set, intercept, etc. named signals and signals in range SIGRTMIN .. SIGRTMAX. glibc uses a few realtime signals for itself (e.g. SIGRT_0 for cancellation and SIGRT_1 for process wide credential changes), and SIGRTMIN expands to a function call which returns the lowest 32 .. 64 value that is available to user programs: #include <signal.h> #include <stdio.h> int main (void) { printf ("%d %d\n", SIGRTMIN, SIGRTMAX); } prints 34 64 here.