> 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.
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. - 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 > >
