Red Hat Bugzilla – Bug 190817
Wrong process name in /proc/<pid>/status for setuid processes.
Last modified: 2015-05-04 21:32:24 EDT
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
Version-Release number of selected component (if applicable):
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
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.
/proc/<pid>/status should have daemon process name not suid_libia32x.s.
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
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
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
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.