Michael Ash <mike@mikeash.com> wrote:
# In comp.sys.mac.programmer.misc SM Ryan <wyrmwif@tango-sierra-oscar-foxtro
t-tango.fake.org> wrote:
# > This short program
# >
# >        #import <AppKit/NSApplication.h>
# >        int main(int argc, const char * argv[]) {
# >                [NSApplication sharedApplication];
# >                return 0;
# >        }
# >
# > when compiled and setuid root
# >
# >        chown root daemon
# >        chmod a+x,u+s daemon
# >
# > gets on a SIGBUS when run as a daemon (outside of process manager) on
# > some systems. Does anybody have any ideas how to deal with this?
#
# Given the number of places that a GUI application will load bits of
# external code from, making it suid root is basically screaming, "please
# hack me, and use me as a local root exploit!" Don't do this.

That's nice, if somewhat irrelevant. The actual program is a few thousand
lines of objective-C that setuids under a safe user. This is a minimal test
case that demonstrates the problem. euid root processes are allowed to
connect to the windowserver outside the Process Manager.

On this system, at least, that cause an SIGBUS inside the Application Kit.
I can find no references to what would cause a SIGBUS, and I don't have
access to the source code up the hill in Cupertino. My past experience is
Apple does not respond very quickly to bug reports from mere programmers.

That's why I'm asking if anybody might know what causes this and/or how
I can work around it without having to port all the image processing
and Postscript interpretter code that NSImage has access just to avoid
using NSImage for image processing on behald of a web application. I was
not asking for a critique on a throw away test case.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
There are subtler ways of badgering a witness.

[ Post a follow-up to this message ]