I can confirm Oli's trick of copying auvaltool to some non-protected location works fine. Added it to our build scripts...
Thanks Oli & Brian for your input! -Stefan > Am 11.10.2017 um 21:17 schrieb Oliver Larkin <[email protected]>: > > hi stefan, > > i copied the auvaltool binary out of /usr/bin to ~/Dev and can launch it from > there without trouble > > oli > Am 11.10.2017 um 21:55 schrieb Brian Willoughby <[email protected]>: > > > On Oct 10, 2017, at 7:47 AM, Stefan Gretscher <[email protected]> wrote: >> since upgrading from El Captain to High Sierra I can no longer directly run >> auval from the Xcode: >> >> Message from debugger: cannot attach to process due to System Integrity >> Protection >> Program ended with exit code: -1 >> >> What is the best/recommended way to deal with this? Disabling System >> Integrity Protection altogether just in order to debug with auval seems over >> the top... >> What's the reasoning behind disabling debugging with auval in first place? > > I assume that this is a side-effect of increasing security in general. I > highly doubt that the goal was to disable auval specifically. There are > probably a few other utilities from /usr/bin/ that no longer work. This > sounds like an oversight, where the test team didn’t check esoteric tools > that aren’t used by typical customers. > > Brian > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/sgretscher%40celemony.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
