Bug 190817 - Wrong process name in /proc/<pid>/status for setuid processes.
Wrong process name in /proc/<pid>/status for setuid processes.
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ia32el (Show other bugs)
ia64 Linux
medium Severity urgent
: ---
: ---
Assigned To: Petr Machata
Depends On:
  Show dependency treegraph
Reported: 2006-05-05 09:48 EDT by Somashekar M
Modified: 2015-05-04 21:32 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-08 13:50:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Tar containing executable and source for the sample daemon (20.00 KB, application/x-tar)
2006-05-05 09:48 EDT, Somashekar M
no flags Details

  None (edit)
Description Somashekar M 2006-05-05 09:48:29 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):
#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:
Comment 1 Somashekar M 2006-05-05 09:48:30 EDT
Created attachment 128657 [details]
Tar containing executable and source for the sample daemon
Comment 2 Eric Lin 2006-05-16 05:15:40 EDT
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? 

Comment 3 Somashekar M 2006-05-17 02:03:07 EDT
Our customers are little bit reluctant to move to the new version of the OS.
Is it possible to have fix for this problem?
Comment 4 Eric Lin 2006-05-23 00:53:49 EDT
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. 
Comment 5 Eric Lin 2006-05-25 00:56:27 EDT
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? 
Comment 7 Petr Machata 2007-05-23 10:39:32 EDT
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.
Comment 8 Ronald Pacheco 2008-02-08 13:50:16 EST
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.

Note You need to log in before you can comment on or make changes to this bug.