[KDE/Mac] Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
René J.V. Bertin
rjvbertin at gmail.com
Sat Sep 20 10:14:35 UTC 2014
> On Sept. 18, 2014, 11:19 a.m., Thomas Lübking wrote:
> > drkonqi/main.cpp, line 47
> > <https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47>
> >
> > this sounds fishy - at least the comment to be incorrect?
> > i hope that OSX does not just actually abort() when you call setuid() but that indeed the tests fail and the applications exits(255)?
> >
> > In case of the latter, does the process itself run with suid until this point?
> >
> > I assume if we've to consider that drkonqi does not (require) to run suid, the test should be omitted if "geteuid()" (notice the "e"!) isn't 0.
> >
> > Skipping this altogether only makes sense for broken by design operating systems which fail to confirm to posix standards (windows ;-)
>
> Ian Wadham wrote:
> I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of setuid/setgid a security breach (it calls it "setugid"). It is part of new security rules that came into OS X about 4 versions ago.
>
> The question is moot, because I am not attempting to run Dr Konqi via kdeinit4 any more, only by forking (see review 119497).
>
> So I propose to settle the issue by removing the Q_OS_MAC condition. I intend to leave in the comment, however, to remind me to do something at this point if I ever get the help I have asked for with the many problems in kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5.
>
> All the tests I did on this in July showed that the crashing app, kdeinit4 and Dr Konqi were all running as the logged-in user and no actual setting of uid or gid was needed. They would just set things to what they were before. Also none of the executable files had any special permission bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the machine somehow.
>
> FWIW the Apple OS X console log said, back in July:
>
> 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING KCrash::defaultCrashHandler (1623294600)...
> 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... crashRecursionCounter = 2
> 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 14165
> 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler -psn_0_327760
> 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit
> 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0
> 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got EXEC_NEW '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' from wrapper.
> 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: preparing to launch /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi
> 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
> 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
> 22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID is running setugid(), which is not allowed.
> 22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 16:30:34.545 drkonqi[14167:2503] The application with bundle ID is running setugid(), which is not allowed.
> 22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 14167 terminated.
>
> René J.V. Bertin wrote:
> Ian, do you think this could in any way be related to the fact that one must do "certain permissions-related things" in order the be able to use a non-Apple-provided debugger? (Which in turn might have something to do with preventing too easy reverse-engineering and other hacker business?)
>
> Ian Wadham wrote:
> No. Dr K works fine if you start it by forking, including the uid/gid stuff. And I am pretty sure MacPorts implements a way to provide access to debuggers of all stripes. That came up on macports-dev list a few months ago.
>
> René J.V. Bertin wrote:
> Yes, it (MacPorts) does. But one that involves something like a code-signing certificate, IIRC. In other words, it seems to be linked to the executable. OTOH, Dr K launches a standalone debugger, so as long as that application has the necessary permissions, all should be fine.
>
> Ian Wadham wrote:
> There have been no problems with hooking up to the crashed app and getting raw backtrace data, only with re-formatting that data. So I see no reason to go into all that at this stage. It is not part of this patch and review.
>
> My next order of priority is to bring the security checking in Dr Konqi up-to-date with Bugzilla software and bugs.kde.org, allowing bug reports to be filed properly on bugs.kde.org in Linux too, but that will be a different patch and a different review.
>
> Thomas Lübking wrote:
> The issue seems not *dropping* permissions, but attempting to run a binary with the suid bit in the first place:
>
> -------
> setuid/setgid apps disallowed
> As a security measure, SnowLeopard takes steps to prevent applications that use AppKit from running setuid or setgid. If AppKit detects that it is running issetugid(), the following will happen:
>
> Under 64 bit, it will log a message and then exit(EXIT_FAILURE).
>
> Under 32 bit, it will give the user a chance to authenticate as an administrator. If the attempt succeeds, the app will run as normal; if the user fails to authenticate, or cancels, it will exit(EXIT_FAILURE). If the attempt fails because the authentication dialog could not be shown, then it will perform a linked on or after check. Apps linked before SnowLeopard will be allowed to run; applications linked on or after SnowLeopard will be exited.
>
> This only affects applications that have the setuid or setgid Unix permission bit set, or apps that inherit this bit from a fork() of a setugid app. This does not affect applications run via sudo, su, or normally as root
> -------
>
>
> -> *is* drkonqui actually 6755 or 4755 on OSX? (it's not on linux, but makes use of special debugger registration)
> -> can drkonqui run as normal user or only as root (since suid is apparently not possible)
>
> Ian Wadham wrote:
> Please re-read what I said a few posts ago, 1 day, 15 hours ago (Sept. 18, 2014, 10:46 a.m.). This question is "moot", meaning "irrelevant", "academic" or "not applicable", because I am no longer attempting to start Dr Konqi via kdeinit4 on Apple OS X and it is only under that condition that there is any problem with "setugid" and Apple OS X. See also https://git.reviewboard.kde.org/r/119497/ and my comment, as follows, on my changes to the original patch:
>
> "The proposed changes to kinit/kinit.cpp (kdeinit4) have been discontinued temporarily. This is because I appealed for help and answers to some questions about kdeinit4, klauncher, kwrapper and kded4 and how they should interact with each other and with applications, but I was not able to get that help and those answers. So KDE 4 software on MacPorts and Apple OS X will continue as before, making minimal to zero use of those background processes."
>
> I have removed the Q_OS_MAC condition at the start of Dr Konqi's main() program and have re-tested that the code involving setuid/setgid works OK when Dr K is started by forking from KCrash. There are no suid bits on Dr Konqi. And that should be the end of this discussion.
>
> Thomas Lübking wrote:
> Yes, I understood that =)
> I was wondering about Apples concern in general, rather than trying to delay the patch. Sorry for not being clear about this.
>
> Because *dropping* privs should not be a security issue, should it?
>
> Thus I wondered whether drkonqi is suid (what wouldn't matter if you additionally call it as uid 0, eg. via sudo) - what it is not here (nor is kdeinit4)
> Since that's apparently not the case and setuid seems actually idempotent, this smells like a wormy Apple to me.
More like an Apple treated with some very nasty and unhealthy stuff to Keep Out Open Source and us being treated like worms by Apple? Security thingamedoodles with gdb (which I have yet to get to work on OS X 10.9) are one thing, but wait until you get to developing kernel and filesystem extensions...
- René J.V.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review66817
-----------------------------------------------------------
On Sept. 18, 2014, 12:57 p.m., Ian Wadham wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119498/
> -----------------------------------------------------------
>
> (Updated Sept. 18, 2014, 12:57 p.m.)
>
>
> Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne.
>
>
> Repository: kde-runtime
>
>
> Description
> -------
>
> When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of "Why does nobody report the problem(s) on bugs.kde.org?"
>
> It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks.
>
> So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two...
>
> In this review we have three portability problems:
>
> 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X "open" command, it always appears on top. The patch just raises the dialog box.
>
> 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now.
>
> 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in.
>
>
> Diffs
> -----
>
> drkonqi/gdbhighlighter.cpp 7cd0aa9
> drkonqi/main.cpp 75e060e
> drkonqi/reportassistantpages_bugzilla.cpp 86ca327
>
> Diff: https://git.reviewboard.kde.org/r/119498/diff/
>
>
> Testing
> -------
>
> Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome.
>
> Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998.
>
> I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software.
>
> Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often fails to complete the backtrace report and then fails to connect to bugs.kde.org.
>
> With my patches, Dr Konqi on Apple OS X can generate a full crash report, including the backtrace and the results of the dialog with the user. Sometimes, however, it fails to submit the completed report to bugs.kde.org. This problem is still under investigation.
>
> I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning.
>
>
> File Attachments
> ----------------
>
> Log of Dr K ASSERT problem
> https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt
>
>
> Thanks,
>
> Ian Wadham
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20140920/97a3a72b/attachment-0001.html>
More information about the kde-mac
mailing list