Description of problem: ia32el service does not show the proper name of the process if setuid bit is set for that process while running as non-root as well as root.(Name present in file /proc/<pid>/status) Version-Release number of selected component (if applicable): #uname -a Linux lcdia02.india.hp.com 2.4.21-37.EL #1 SMP Wed Sep 7 13:24:42 EDT 2005 ia64 ia64 ia64 GNU/Linux How reproducible: Create a sample daemon and set the setuid bit for that daemon and run it as non-root/root.Then check the file /proc/<pid>/status the process will always be shown as suid_libia32x.s instead of the actual process name. Steps to Reproduce: 1.Create a sample daemon 2.chmod 4550 <daemon> 3.Run the daemon file as root/non-root 4.Check the file /proc/<pid>/status file the process name 5.The Name will be suid_libia32x.s instead of daemon process name. Actual results: Expected results: /proc/<pid>/status should have daemon process name not suid_libia32x.s. Additional info:
Created attachment 128657 [details] Tar containing executable and source for the sample daemon
This is a compability issue in 2.4 kernel. IA-32 EL uses binfmt_misc to register itself as ELF32 interpreter. IA-32 EL handles setuid binaries as following: IA-32 EL provides two binaries: libia32x.so and suid_libia32x.so, where libia32x.so is registered as ELF32 interpreter and suid_libia32x.so is setuid. libia32x.so checks the permission on IA-32 binaries - if invokes suid, libia32x.so invokes suid-libia32x.so via execve(). So for non-setuid binary, the kernel will do special handling for binfmt_misc so that /proc/<pid>/status shows the name of IA-32 binary instead of the interpreter (libia32x.so) - while after libia32x.so does execve(), the name will be changed to suid_libia32x.so. There is a solution in 2.6 kernel for suid issue, the kernel will use crendential of IA-32 binaries instead of credential of interperter as the euid and egid - so suid_libia32x.so is not necessary any more and as a result, you will not observe such incompatiblity. Can we suggest you to upgrade to RHEL 4 series?
Our customers are little bit reluctant to move to the new version of the OS. Is it possible to have fix for this problem?
We have a possible workaround for EL 3 series (2.4x kernel): create a temp soft link whose name is same as the 32-bit binary to suid_libia32x.so, and then invoke execve(âtemp link nameâ). We are currently validating the fix.
We just found our workaround doesn't work correctly if more than one setuid application are executed. So we have no way to fix it except kernel patch - is it acceptable?
To reporter: is this still an issue for you? This bug has been inactive for several months now. If this still is an issue, is the kernel patch offered by Eric Lin acceptable? This is probably the only way to fix this problem.
This has been in needinfo since 5/25/06 and we do not have an update. I will close this as "notabug". If this is still an issue, then please reopen.