Red Hat Bugzilla – Bug 473907
Using seteuid or setegid in a thread causes SIGRT_1 to be delivered
Last modified: 2008-12-01 09:13:28 EST
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
Version-Release number of selected component (if applicable):
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 ...>
see above. No problem with this simple program, but with software
from other vendor, e.g. eDirectory from Novell.
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:
printf ("%d %d\n", SIGRTMIN, SIGRTMAX);
prints 34 64 here.