[jordigh]

Yes, but that's not the whole OS. Where do your rights end to inspect the software and hardware you bought?

Also, I was careful to not say legal/illegal but allowed/disallowed. I am pretty sure that macOS disables some debugging calls, or at least it used to. What are the limits?

[comex]

I can think of two different things that could match your description:

- An old call, ptrace(PT_DENY_ATTACH), which prevents the process that calls it from being debugged (with either ptrace or dtrace). iTunes calls this. It's always been rather easy to circumvent, either by attaching before the process has the chance to make the call, or by installing a kext that disables the functionality.

- System Integrity Protection broadly prohibits debugging of system processes, as well as kernel tracing via dtrace. But SIP can be disabled by the user, by design.

Kernel debugging in particular is explicitly supported by Apple in the form of Kernel Debug Kits, which consist of debug symbols for the open source parts of the kernel, as well as variant builds with more debugging stuff enabled at compile time. Peeking at the proprietary parts is presumably against the license agreement but not technically restricted in any way (hard to imagine what such a restriction would look like).

[jordigh]

Thanks, the iTunes case was what I was thinking of.

[bazinga888]

Not to be rude, but why do you care?

If it's illegal, it's up to Apple to deal with it. Why go out of the way doing free work for them?

[jordigh]

Because it has affected me in the past. I've had to debug stuff in the past in macOS, thinking it would be similar to BSD, and was thwarted by technical means to disable debuggers. I've found the experience quite distasteful and was trying to remember what the problems were that I faced.

[Luc]

Politics. He's trying to lead us to to the Freedom of the GPL in this Socratic fashion.

[unixhero]

My thoughts exactly :-)

[mee_too]

So that he looks smart.