> On Sept. 18, 2014, 9:19 vorm., 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.
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. - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/#review66817 ----------------------------------------------------------- On Sept. 18, 2014, 10:57 vorm., Ian Wadham wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119498/ > ----------------------------------------------------------- > > (Updated Sept. 18, 2014, 10:57 vorm.) > > > 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 > >
