Skip to content

security – When relocating a home folder to another Volume, how do you resolve Sandbox errors for the new root .TemporaryItems folder?

  • by


Summary:

I migrated my user data to a new APFS volume to mitigate upgrade issues with Ventura, but I am now experiencing high CPU usage with syncdefaultsd and secd due to permission issues. I need help to adjust Sandbox settings without breaking the security or stability of the system.


Details:

After some very lengthy “wars” with a multi-failed attempt to “upgrade” to Ventura, I was finally able to get some relief/success by first migrating my user data to a new APFS volume that lives beside the “system” volume. Apparently Apple engineers seem to believe this is the best course of action presently so as to mitigate “headaches” from failed upgrades and other issues…

When doing this I discovered that this works rather well, but I noticed that syncdefaultsd was running quite high on the CPUs. Looking into the logs more closely I found that both it and secd are having a problem with permission to the new user storage location, eg my new home folder is at /Volumes/data/Users/username and the error in question is:

...
1   <Missing Description>       kernel  Sandbox: secd(16636) deny(1) file-write-create /Volumes/data/.TemporaryItems/folders.501/TemporaryItems/path    0   0: 0x95619f error   17:57:51.167515-0400
...
1   <Missing Description>       kernel  Sandbox: syncdefaultsd(670) deny(1) file-write-create /Volumes/data/.TemporaryItems/folders.501/TemporaryItems/path 0   0: 0x956f00 error   17:58:00.614794-0400
...

What is the appropriate or acceptable method to deal with this without breaking Apple’s methodology here?

Clearly (Seatbelt) Sandbox isn’t configured to facilitate this and/or some system setting in Ventura is not liking the automatic move that macOS did to put .TemporaryItems into the new volume’s root path.

I don’t like the idea of removing all permissions on the drive and if I manually set them, a system service automatically re’chowns the folder to root:wheel, so I’m not seeing any clean or clear paths past this.

Another option, that would not be considered kosher, is to mount the System volume +rw and modify com.apple.secd.sb and com.apple.syncdefaultsd.sb in /System/Library/Sandbox/Profiles/ so as to add:

(allow file-write-create
    (subpath "/Volumes/data/.TemporaryItems"))

Such that com.apple.secd.sb would be:

(version 1)

(deny default)

(import "system.sb")

(allow file-write-data
    (literal "/dev/random"))

(allow file-write-create
    (subpath "/Volumes/data/.TemporaryItems"))

(allow file-read* file-write*
    (subpath "/private/var/db/mds")
...

And com.apple.syncdefaultsd.sb would have this inserted:

...
(allow user-preference-read
    (preference-domain "com.apple.CloudKit")
    (preference-domain "kCFPreferencesAnyApplication"))

;; Read/write access to a temporary directory
(allow file-read* file-write*
    (subpath (param "TMPDIR"))
    (subpath (param "DARWIN_CACHE_DIR"))
    (subpath "/Volumes/data/.TemporaryItems"))
       
;; Read ourselves
(allow file-read*
    (subpath (param "SELF_PATH")))
...

But this is clearly both fragile and “insecure”… Thus my question: how should such a situation be handled when moving the home folder to a different volume and needing to accomadate Apple’s Sandboxing?

Leave a Reply

Your email address will not be published. Required fields are marked *