setuuid/setguuid

[Ian Wadham]

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 rjvbertin at gmail.com 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.