The get_credentials() function in access_control.py will generate an exception when it calls socket.getsockopt() on powerpc (ppc). This was occurring because the SO_PEERCRED constant was not exported by the python socket module and had been hardcoded to 17 to work around the problem. But the value of SO_PEERCRED is not always 17 on all architectures, in particular on ppc it's 21. A discussion of the issue can be found in bug #436560.
A patch has been prepared which takes account of the architecture and wraps the logic in a try/except block to further assure no exception will be generated.
Created attachment 297260 [details] patch to set SO_PEERCRED based on arch
John, re: release notes for this item, is this issue specific to PPC? also, could you clarify the user impact of the bug that was fixed (e.g. causes a crash when user does X)? thanks!
re comment #3 The issue is specific to PPC *only*. The setroubleshootd daemon will exit with a fault the first time the desktop program sealert connects to the daemon. The sealert will display the error "cannot connect" because the daemon it's trying to connect to has aborted.
sorry for the late reply, added to RHEL5.2 release notes under "Known Issues" (ppc only): <quote> (ppc) The setroubleshootd daemon will exit with a fault the first time sealert attempts to connect to the daemon. As such, sealert will display a Cannot connect error when it is run. Note that when this error occurs, the following sealert features will be disabled: * Real-time notification of SELinux AVC denials * The ability to browse diagnostic information associated with SELinux AVC denials </quote> please advise if any further revisions are required. thanks!
John, should we mark this as resolved in the release notes? please advise. thanks!
re comment #12, from my perspective it's resolved, however officially it's not resolved until QE marks it as so.
Hi, the RHEL5.2 release notes will be dropped to translation on April 15, 2008, at which point no further additions or revisions will be entertained. a mockup of the RHEL5.2 release notes can be viewed at the following link: http://intranet.corp.redhat.com/ic/intranet/RHEL5u2relnotesmockup.html please use the aforementioned link to verify if your bugzilla is already in the release notes (if it needs to be). each item in the release notes contains a link to its original bug; as such, you can search through the release notes by bug number. Cheers, Don
looks like it's already resolved. can we now document this as "Resolved" in the RHEL5.2 release notes updates? please advise. thanks!
I don't think this needs to be in the release notes, this particular issue only arose in the initial 5.2 update submission, not a previous version, thus it is only known as an issue to our internal testing group.
thanks John. removing entirely from release notes.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2008-0061.html