https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8043
--- Comment #10 from Sidney Markowitz <[email protected]> --- Created attachment 5818 --> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5818&action=edit patch to handle spamd launched with gid of supplemental group instead of primary group In deciding whether the real gid needs to be changed, setuid_to_euid checks whether it currently equals the primary group of the user specified by the effective uid. The idea is that we are about to set real uid to the value of the effective uid, so the real gid should be the group corresponding to that uid. It is necessary to look at that instead of the effective gid because it is possible to set the euid to some user value while leaving the effective gid set to root. In the use case of this bug, spamd is being launched as a service with a gid that the uid is a member of, but is not the primary group of that uid. The fix for this is instead of testing whether real gid is equal to the primary group id, test if it is found in the list of group ids for that uid. In this use case, spamd never has privileges because it wasn't launched as root, so it would be ok to simply not run setuid_to_euid. However, in addition to real uid/gid and effective uid/gid, there is a third pair called saved uid/gid that makes it possible for a process to look like it is not privileged based on the values of the real and effective uids, but still be able to escalate back to root privileges. And perl does not have a way of accessing the saved uid/gid to find out if that is the case. So there is no workaround to running setuid_to euid just in case it is needed. Perl does have a way of ensuring that privileges have been fully dropped and saved uid/gid are non-root, and that is in the setuid_to euid code already. Please check this and vote on committing it for 4.0.0 -- You are receiving this mail because: You are the assignee for the bug.
