Policies failing - "Operation not permitted"

[ooshnoo]

Yo.

A recent couple of new macs were setting up came with Catalina, and I've noticed that when they try to copy packages down from our SMB shares, often times htey fail with a message that states "Operation not permitted"

For example, logs show

Executing Policy VMWare Horizon Client
    Mounting ATL DP
    cp: /Volumes/JamfProShare-ATL/Packages/VMwareHorizon_v5.10.pkg: Operation not permitted

    Error: The package (VMwareHorizon_v5.10.pkg) could not be found.

Any idea what this is and now to fix? I was told it was a brand new Mac and it came with Catalina, so not sure if that has something to do with it.

[DBrowning]

@dng2000 my Notify Script runs all custom triggers. Adding the com.loginwindow pppc worked fine for me as I only have SMB shares internally.

[allanp81]

@ddcdennisb Custom triggers work fine without anything special, as do at recurring check in etc. It's only startup/login/logout that have issues.

[dng2000]

@allanp81 In my environment, custom triggers work fine during recurring check-ins but not during provisioning that runs a bash script that calls the custom event triggers by running the jamf binary. My environment still runs an in-house app that runs DEPNotify and executes a bash script that calls specific groups of custom event triggers based on the user's department determined by the acronym used in the prefix of the determined hostname. So it's still a problem for my environment if and when I have to switch back to SMB. The biggest impact for me is actually two of my Tomcat nodes are literally doubling as the primary and backup HTTPS DP which is not always a healthy load depending on how many machines are running my in-house provisioning app that caches a lot of pkg's in the process.

[allanp81]

@dng2000 I run custom triggers during deployment and they seem to work fine so you should be able to be able to create a profile that allows this.

[dng2000]

@allanp81 Several profiles with various methods have already been attempted without success in my environment. But calling the custom triggers straight from Terminal and calling the bash scripts directly from the command line in Terminal work like a charm. Just not through my MacDeploy.app bundle which means I got more to figure out within my custom-built app when I got time again to deal with that.

[allanp81]

@dng2000 Ah, I see, didn't realise what you meant.

[dng2000]

@allanp81 Curiously, does your environment use https://<url>:8443/enroll for new Mac enrollments or a custom-built App for your own ZTI barring the part on manually approving the MDM? :)

[allanp81]

@dng2000 I use the quickadd package.

[MrRoboto]

I'm using DEPnotify with a launch daemon that runs a Jamf policy with provisioning script. The script calls on other policies to deploy packages via custom triggers. Internally using SMB FSDP and just ran into the "CP operation not permitted" issue while working on Catalina and new 2020 MacBook Airs.

Creating a PPPC for /bin/bash and /bin/sh, with allow Network Volumes and All Files did the trick. I did not have to include Terminal, CP, or loginwindow for things to work.

[dng2000]

@MrRoboto Did you have to check "Validate the Static Code Requirement" for your environment? I use DEPnotify too but via a custom-built in-house app called ITFS-MacDeploy that my former co-worker developed. I set this problem aside in my environment for the past 2 months and haven't got back to troubleshooting this for my existing environment.

[MrRoboto]

@dng2000 No I did not... just /bin/bash and /bin/sh, with allow Network Volumes and All Files. I also allowed /bin/sh to AppleSystemEvents for my re-naming script to work, and allowed Terminal to NetworkVolumes for manually running policies when needed.

[stephenb]

Do the following to whitelist stuff happening at logout:

Whitelist /System/Library/CoreServices/sessionlogoutd, using the identifier type path, with the code requirement identifier "com.apple.sessionlogoutd" and anchor apple

sessionlogoutd is the responsible binary that handles logout hooks, in the same way that loginwindow handles login hooks. Therefore, any logout hook script set here (including the Jamf logout policy process) will have access to anything that TCC allows, if the profile is set as per above.

In the example here, I'm allowing the logout process access to all files, network shares, and removable drives. Essentially to allow a Jamf Pro policy, fired at logout, to sync data to a network drive using rsync.