Bug 190817
Summary: | Wrong process name in /proc/<pid>/status for setuid processes. | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Somashekar M <somashekar.m> | ||||
Component: | ia32el | Assignee: | Petr Machata <pmachata> | ||||
Status: | CLOSED NOTABUG | QA Contact: | |||||
Severity: | urgent | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 3.0 | CC: | eric.lin, mnewsome | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | ia64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-02-08 18:50:16 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Somashekar M
2006-05-05 13:48:29 UTC
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. |