简体   繁体   中英

macOS Privileged Helper doesn't have access to a filesystem path?

Halp! I am writing an internal macOS app for our IT staff to perform some org-specific tasks, and am also adding some shortcuts for simple, but common tasks that they do. One of those tasks is to rename a user when migrating between domains. This app has a Privileged Helper available (via SMjobBless ) to perform most of the tasks. However, it appears that this helper tool, despite its privileged execution context, is unable to rename a user's home directory.

My first attempt at implementing this specific task in the helper was to run a short shell script via Process() (a technique used successfully for dozens of other tasks in this helper).

let script = """
            set -e
            mv '\(homeDirPath)' /Users/\(toUsername)
            dscl . -change /Users/\(fromUsername) NFSHomeDirectory '\(homeDirPath)' '/Users/\(toUsername)'
            dscl . -change /Users/\(fromUsername) RecordName \(fromUsername) \(toUsername)
            """

I get the following output on stderr ( /Users/newname verified to not exist):

mv: rename /Users/oldname to /Users/newname: Operation not permitted

Trying this as a non-root user gives a different error: mv: rename /Users/oldname to /Users/newname: Permission denied

Okay, weird. Add whoami to the top of the script to double check the user context: root . Well... interesting. Wth, I can do this just fine via sudo in my user session.

Then I try using FileManager thinking there might be some SIP interference or sandboxing for child processes of a launchdaemon (despite not finding any docs that say this), but I still get an error - but more verbose this time:

Error: “oldname” couldn't be moved because you don't have permission to access “Users” .

I've tried searching for documentation for whatever restriction I am up against, but I'm at a loss. The directory doesn't appear to be under SIP's protection, and I can't find any docs for daemon sandboxing outside of the app store (the parent app does not have the App Sandbox capability enabled). Can anyone point me in the right direction?

Update: It doesn't appear to be affected by 10.14's Privacy Protection. Adding the helper to "Full Disk Access" doesn't resolve. Perhaps I am adding the helper incorrectly: had to change the build target to 10.14 (which will be a problem), then dragged the helper binary from within the App bundle into the list. I cannot add it from /Library/PrivilegedHelperTools/ - it is greyed out as an option to add.

Update 2: Correction, it does appear to be FDA related. iTerm was in the FDA list. Removing it causes it to throw Operation not permitted , then adding it back resolves. So I'm now chasing down how to properly add the helper to the FDA list.

Okay, it's confirmed - Mojave's Privacy Protections apply even to privileged tools. The solution was to make the helper binary executable by all so it can be allowed to be added to the Full Disk Access table.

Hopefully, this helps someone in the future who is initially puzzled by what they're seeing.

Here's to hoping that Apple adds a standardized, easier method for the user to grant this access to helpers.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM