-
Notifications
You must be signed in to change notification settings - Fork 582
Mac OS X kernel sandbox system policy errors are back #449
Comments
@mklein-de Do you have any idea? I thought the |
With htop installed from Homebrew, reverting back to 2.0.0 eliminates the errors. |
Oh. I just realized that to get detailed process information, htop 2.0.1 uses According to the above link, it seems I need to add a PropertyList file (which I haven't figured out what it is yet) and add some initialization code to the source to get proper capabilities. I can add the initialization code to the source, but it won't do much good unless the binaries are signed. Paging @MikeMcQuaid: Does Homebrew ship signed binaries? |
@47ronin I added a minor tweak now that makes it try only once per process. It's not yet a full solution but it should alleviate the issue. If possible, please try to build from current Git and let me know if it works better. |
@hishamhm It does not, sorry. |
Removed all traces of the Homebrew htop versions 2.0.0 and 2.0.1, then installed from Git source (master)
With
|
@47ronin does it keep appearing at the same rate? Or does it show a bunch of errors at start up and then stops? (This is what I'd expect) |
Hi, this has nothing to do with the I think you are right with the need for the Regarding the try-only-once-per process hack: With 2.0.1:
With
|
@mklein-de Thanks for testing! So what's the situation with these permission errors? Are we allowed to call Or if we get one failure we can assume that the |
According to https://en.wikipedia.org/wiki/System_Integrity_Protection, the protection applies to executables residing in certain system directories like This is consistent with the observation that I guess the try-once-per-process approach is the best we can do here. |
Seems like you have to pay money to apple if you desier to develop 'process monitor' apps. It is apple ps.c has entitlements.plist file, with 'task_for_pid-allow' parameter requires paid subscription. http://opensource.apple.com/source/adv_cmds/adv_cmds-163/ps/ codesign -s - --entitlements entitlements.plist -f htop This is only possible if you a paid developer. Which means it gives you no additional protection from 'hackers' but involves money. I think it is very bad move from Apple, 'bad' people always can find the way to infect your machine even with signed code, or leaked keys, but it just strip good people from using Apple hardware. Console Log: Crash Report: |
Duplicate of #330, which is the first thing that comes up in a google search. |
@tlhunter not really a duplicate because this is from the official build that now supports OS X. It worked flawlessly in v2.0 but subsequent updates within the last month or two caused the errors to reoccur. |
Just trying to help the googlers ;) |
@47ronin the errors returned because htop is now trying to read more accurate info, and it only realizes whether it can read that data or not after it tries at least once. It's a tough situation. 2.0 was not working flawlessly — it didn't spill errors to the log, but it displayed incorrect data. Unfortunately it seems we can't have it all. :-\ |
press ignore sender in the Console and you're done with that message :) |
Would it be possible to not try again after it realized that it cannot read the data instead of trying over and over again?
A pretty difficult advise, considering you are going to ignore all kernel messages with that. |
@wagnerand This is what htop is doing now in current Git. Though it tries at least once for each new process that comes up, because it doesn't know in advance if it will have permissions for that process or not. |
@hishamhm Indeed it's much better with this change, thanks! There are still some log messages at htop startup, and when new PIDs appear, but not continuously. As a side note, with rootless disabled ('csrutil status' says 'disabled'), task_for_pid access isn't restricted, BUT the system will log EVERY SINGLE CALL anyway. Prior to updating htop to trunk (using the 2.0.1 build in Homebrew), running htop (with -d 5) as root resulted in: kernel[0] : Sandbox: htop(51550) System Policy: allow(0) mach-priv-task-port ... continuously. In that state on an otherwise idle system, syslogd is the busiest process on the system. In trunk (I'm on 7f9c82f), it's a little better: kernel[0] : Sandbox: htop(624) System Policy: allow(0) mach-priv-task-port I wrote some quick ASL rules that reduce syslogd CPU usage by about 50%, and eliminate the 'allowed mac-priv-task-port' log spam entirely.
Activate with: |
IMO, this should be a prioritized thing to fix. Since the OSX/macOS's top is awful, I had been using htop when I saw my CPU load going up unexplained. With htop making the syslogd go crazy too, it makes life worse to try to see what's wrong. For the moment, I'm back to using Activity Monitor. I don't know for sure, but in my gut I feel like a command-line app should be lighter-weight than a GUI one. |
A new release is coming soon, with the improved behavior that's already in Git. |
Thanks for releasing 2.0.2. Brew picked it up and the console logs are now no longer completely insane. Much appreciated! |
A partial solution is to sign the htop binary with a certificate present in the System keychain. The certificate can be self-signed. See https://sourceware.org/gdb/wiki/BuildingOnDarwin#Method_for_Mac_OS_X_10.5_.28Leopard.29_and_later for how this works with gdb. A subtlety is that the certificate must be in the System keychain, not the login keychain. However I have found that even so, htop will be denied permission to inspect many processes. |
@doc-crowston Interesting! — which processes are you able to inspect with this option and which one you are not? Could you send a screenshot? |
For anyone running
|
Mac OS X El Capitan v10.11.3 here. Log is spilling with these:
3/15/16 15:00:52.000 kernel[0]: Sandbox: htop(939) System Policy: deny(1) mach-priv-task-port 107
after runningsudo htop
😢The text was updated successfully, but these errors were encountered: