On 24/12/2014, at 8:52 AM, Joshua Root wrote: > On 2014-12-24 08:15 , Ian Wadham wrote: >> Hi Clemens, >> >> On 23/12/2014, at 11:33 PM, Clemens Lang wrote: >>> ----- On 23 Dec, 2014, at 13:02, René J.V. Bertin [email protected] wrote: >>>> IIRC, OS X no longer allows setuuid/setguuid, or only under some >>>> conditions. >>>> Isn't that something that ought to be addressed in the post-destroot? >>>> I'd vote for removing the offending flags if they cannot have their >>>> intended >>>> effect anyway. >>> >>> That's the first time I hear of that. Unless you have a source you can >>> quote on >>> that I'm not going to believe you, especially since my SUID (not setuuid, >>> that's >>> not a thing) binaries still work as I expect them to. >> >> Is this topic anything to do with the following Apple OS X message? >> "The application with bundle ID (null) is running setugid(), which is not >> allowed." >> Google on "Apple setugid". That message has been giving people trouble for >> a couple of years at least. "setugid()" is Apple's shorthand for (regexp) >> "set[ug]id()". >> >> I used to get the message from Dr Konqi (KDE's crash analyser), till I >> bypassed >> the offending code by stopping KCrash from trying to run Dr Konqi via >> kdeinit4. >> >> The source for main.cpp of Dr Konqi currently reads: >> >> ------------------------------------- >> int main(int argc, char* argv[]) >> { >> #ifndef Q_OS_WIN //krazy:exclude=cpp >> // TODO - Investigate and fix this, or work around it as follows... >> // #if !defined(Q_OS_WIN) && !defined(Q_OS_MAC) >> // When starting Dr Konqi via kdeinit4, Apple OS X aborts us unconditionally >> for >> // using setgid/setuid, even if the privs were those of the logged-in user. >> // Drop privs. >> setgid(getgid()); >> if (setuid(getuid()) < 0 && geteuid() != getuid()) { >> exit(255); >> } >> #endif >> ------------------------------------- >> >> The notes are to remind me to investigate this problem further if I ever get >> kdeinit4 (or kdeinit5) to work properly on Apple OS X and MacPorts. > > Does this code run as root?
Normally no. > If not, setgid and setuid will not work. You > might try wrapping the whole thing in a getuid() == 0 check. Thanks for the suggestion, Joshua. > Also, the "setgid(getgid());" seems a bit suspect. I can only assume > it's there to reset the egid by side effect? An explicit setegid would > be a lot more clear in that case. The Dr Konqi code is a crash analyser and is supposed to run without special privileges, even if the program that crashed had such privileges. I think the code is trying to ensure or restore normal user privileges. The code always seems to work OK if the crash procedure in the failed program starts Dr Konqi by forking. But it never works (on Apple OS X) if the crash procedure contacts an independent process (kdeinit4) via a socket and asks kdeinit4 to run Dr Konqi. Starting via kdeinit4 is preferred to forking, in case the crashed program has a corrupted heap or whatever. All my testing has been with programs that had normal user privileges, i.e. the crashing program, Dr Konqi and kdeinit4. That's the silly thing about this situation. OS X won't let Dr K set privileges it already has. I am not working on this ATM. I just brought it up as an example (for Clemens) of OS X not allowing setuid/setgid. Cheers, Ian W. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
