When starting a process on macOS Sequoia, it gets terminated by the kernel.

Question

Created 4d

Replies 1

Boosts 0

Participants 1

I have an executable file named infogodesk, located in the directory /usr/local/SmpAgent/rustdesk/infogodesk. When I execute it using the terminal with ./infogodesk, the process gets terminated by the kernel. However, if I move the executable to another directory, it works fine.

This issue is very frustrating, and I hope to get some help. Below is the console log output:

默认 11:26:28.162205+0800 kernel ASP: Validation category (6) does not match top-level policy match (3) for process: /usr/local/SmpAgent/rustdesk/infogodesk 默认 11:26:28.162211+0800 kernel Validation category policy: Notifying syspolicyd about /usr/local/SmpAgent/rustdesk/infogodesk with PID 88264 默认 11:26:28.166695+0800 kernel CODE SIGNING: cs_invalid_page(0x104e04000): p=88264[infogodesk] final status 0x23000200, denying page sending SIGKILL 默认 11:26:28.166698+0800 kernel CODE SIGNING: process 88264[infogodesk]: rejecting invalid page at address 0x104e04000 from offset 0x0 in file "/usr/local/SmpAgent/rustdesk/infogodesk" (cs_mtime:1734509326.0 == mtime:1734509326.0) (depth:0) 默认 11:26:28.166738+0800 kernel infogodesk[88264] Corpse allowed 1 of 5 默认 11:26:28.255182+0800 ReportCrash ASI found [ReportCrash] (sensitive) 'Pid 88264 'infogodesk' CORPSE: Extracting Completed 1, Recent: Pid 86766 'ReportCrash' CORPSE' 默认 11:26:28.261619+0800 ReportCrash ASI found [ReportCrash] (sensitive) 'Pid 88264 'infogodesk' CORPSE: Extracting Completed 1, Recent: Pid 86767 'ReportCrash' CORPSE'

Boost

Answer 1

wulc OP

3d

Yesterday, I discovered some clues about the issue, but I still don’t fully understand the cause. My program downloads additional components through a main process called SmpHelp. One of these components, rustdesk, is provided as a ZIP archive. After extracting the ZIP, it contains a rustdesk directory and three subfiles.

Here's the strange part: when I use the unzip command-line tool to extract the archive, the infogodesk process works fine. However, when I use a third-party code library to extract the same archive, the infogodesk process fails to run. Regardless of the extraction method, the MD5 hash values of the executable file are identical, which indicates the file itself is not corrupted.

Even more oddly, if I move the problematic executable to another directory or manually create a new directory for it, the process runs without issue.

Could this behavior be related to differences in the inode attributes or metadata of the directories created by the third-party library versus the ones created by unzip?

I would greatly appreciate any insights into why this might be happening.

0