Jamf Sync Package Permissions

[TimCraftA52]

In my tests the pkg being synced from our cloud repo to our local isilon share is not getting the correct ACL's to function properly

Here is the output from the client trying to download and the ACL info from the nas. Please note pkg (Slack_4.38.121.pkg) was uploaded (synced) from Jamf Admin with correct ACL's and the pkg (Slack_4.38.121_v1.pkg) was uploaded (synced) from Jamf Sync.

CLIENT - macstudio-01:~ root# jamf policy -trigger slack Checking for policies triggered by "slack" for user "timc"... Executing Policy Install Slack 4.38.121 (Universal) Mounting LA cp: /Volumes/fsdp$/Packages/Slack_4.38.121_v1.pkg: Permission denied Error: The package (Slack_4.38.121_v1.pkg) could not be found.

ISILON NAS - perry-1# ls -ldea Slack_4.38.121* -rwxrwxrwx + 1 A52\jamfadmin wheel 192950416 May 13 15:57 Slack_4.38.121.pkg OWNER: user:A52\jamfadmin GROUP: group:wheel CONTROL:sacl_auto_inherited 0: user:A52\jamfclient allow file_gen_read 1: user:A52\jamfadmin allow file_gen_all -rwxrwxrwx + 1 A52\jamfadmin wheel 192950416 May 14 09:19 Slack_4.38.121_v1.pkg OWNER: user:A52\jamfadmin GROUP: group:wheel CONTROL:dacl_auto_inherited,sacl_auto_inherited 0: SID:S-1-5-88-3-384 deny

[HarryStrandJamf]

Is the Isilon NAS associated with the Jamf Pro server via SMB or AFP? Is your cloud repo JCDS2 (Jamf Cloud)? Are you using Jamf Sync version 1.3.0? Is the share name "fsdp$"?

[TimCraftA52]

• SMB
• yes, JCDS2 (jamf cloud)
• yes, Jamf Sync 1.3.0
• yes, the smb share name is fsdp$

[HarryStrandJamf]

So Jamf Admin did it correctly, and Jamf Sync does not, is that correct? Jamf Admin used a function that was long deprecated by Apple. So if Jamf Admin handled it correctly, then that deprecated function must have handled it. I'm not finding info about how to deal with this with Swift (the language Jamf Sync is written in). How important is it that the ACL information is preserved? What are the implications if it's not?

[TimCraftA52]

Yes, jamf admin is and has been working.

The ACL is how the user 'jamfadmin' can read / write for the cloud server and 'jamfclient' can read the files to install for the client. This is set at the core of the jamf setting -> File share distribution points and is required.

Any synced files do not have the proper ACL permissions and might as well not exist.

[HarryStrandJamf]

I'm finding very little information about ACL. It does appear that if I start an external process that uses "/bin/cp -p" to copy files, that would preserve the ACL, however, this would degrade the performance of Jamf Sync. If I were to do this, I would probably add a setting to enable it and default it to disabled. Ideally, I would use something native to Swift that would handle this, but I'm not finding anything. If I could, I would just use it without adding a setting.

[chriskeavey-kkl]

We have the same issue syncing to our macOS Sonoma SMB file shares.

Package permissions set by Jamf Admin will be: -rw-r--r-- Package permissions set by Jamf Sync are: -rw-------

Testing by viewing the distribution point in a web browser results in the file list being displayed but Forbidden You don't have permission to access this resource. when you click to download a package.

Jamf Policies to install packages will report Permission Denied and fail over to the cloud server.

At the moment I am manually running chmod 644 after each sync.

[HarryStrandJamf]

@chriskeavey-kkl, I checked the permissions on my test SMB file share, and I did see a file with the same permissions as yours, however, I tried synchronizing that same file from a local file share and it seems to preserve the permissions that it was set to. If you have read only permissions on your file share and try synchronizing it to a local drive, I wonder if that would affect the file permissions. Is that possibly what caused the issue you were seeing?

[cvgs]

I've got the same problem.

Example: The first file (v5.1.3.62) had been synced using rsync, and inherits every ACLs that are applied to the parent folder). The second file (v5.1.4.74) gets just nothing, no ACLs and not even the correct group or umask:

-rwxr--r--+ 1 root    wheel  160791805 17 Apr 19:30 Packages/Cisco Secure Client_5.1.3.62.pkg
 0: group:admin allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity
 1: group:_www allow read,readattr,readextattr,readsecurity
 2: user:loc_jamf_ro allow read,readattr,readextattr,readsecurity
 3: user:loc_admin allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity
-rw-------  1 loc_admin  staff  162101323 19 Jun 10:22 Packages/Cisco Secure Client_5.1.4.74.pkg

The reason is simple: Jamf Sync usess CFNetworkDownload to a temporary location; where there are no ACLs or default groups to inherit. And after downloading, the file gets simply moved to the final location. But a simple move does not cause permissions or ACLS to change or be re-inherited, so the file carries its loc_admin:staff and -rw------ over to the new location.

The right thing to do would be to copy the file to the destination and remove the temp file. On APFS this should be no performance drawback (because of copy-on-write), and you can be sure you get the inheritances right.

And you would also get around this permission problem (spoiler: there wasn't a permission problem):

24/06/19 10:14:40-ERROR: Failed to copy Cisco Secure Client_5.1.4.74.pkg to LocalJamfTestShare (local): Error Domain=NSCocoaErrorDomain Code=513 "“CFNetworkDownload_6j07cB.tmp” couldn’t be moved because you don’t have permission to access “Packages”."
UserInfo={NSSourceFilePathErrorKey=/var/folders/z4/7w7t4w1d12139f9dbcds89nr0000gp/T/CFNetworkDownload_6j07cB.tmp, 
NSUserStringVariant=(
    Move
),
NSDestinationFilePath=/Users/Shared/JamfTestShare/Packages/Cisco Secure Client_5.1.4.74.pkg,
NSFilePath=/var/folders/z4/7w7t4w1d12139f9dbcds89nr0000gp/T/CFNetworkDownload_6j07cB.tmp,
NSUnderlyingError=0x6000005f35d0 {Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied"}}

[HarryStrandJamf]

@cfgs Thanks for the info. I tried just changing it from a move to a copy and a delete and it didn't help. But at least I see what you mean now. I could check to see what the owner and permissions for the parent directory that it's moving the file to and set the file's owner and permission to the same. Is that what would be expected? The ACL is tougher since I can't seem to find much info about that, but I'll keep looking. The tiny bit I did find out made it look like it would have to be run as sudo, which I guess it should work to do if launched from terminal. Do you know if that's the case?

[cvgs]

You can easily test it yourself by adding ACLs to your directory:

mkdir /tmp/acltest
chmod +a "group:_www allow list,search,readattr,readextattr,readsecurity,file_inherit,directory_inherit" /tmp/acltest
touch /tmp/exhibit_a /tmp/acltest/exhibit_b
mv /tmp/exhibit_a /tmp/acltest
ls -lea /tmp/acltest

You'll see that exhibit_a did not get any ACLs, but exhibit_b did, and thus should be readable by the group _www (which will allow apache to serve the file over HTTPS if configured correctly).

The actual user and group setting is not that important, because you can "fix" everything by adding the proper ACLs anyway, so i wouldn't worry about that too much. And i'd especially avoid introducing sudo into the mix.

If you want to read about ACLs, there's this oldie but goldie: https://arstechnica.com/gadgets/2005/04/macosx-10-4/8/#acls

[HarryStrandJamf]

Thanks @cvgs! That's great info! I was able to use that info to make a change so when downloading files, it will retain the Posix and ACL permissions that are used when creating new files in the destination directory. Copying from one local folder to another (or file share distribution point since that is treated as a local folder when mounted) will continue to work the same as it had, where it will retain the source permissions including the ACL, provided that the destination directory also has ACL. This change should be available with version 1.3.1.

I can't believe I've been at Jamf for almost 14 years and hadn't heard about ACL before now! I asked someone else here if they had heard of ACL...they said "Not in that context, but I tore my ACL!" I guess everything just happened to work behind the scenes before so we didn't have to deal with it.

[HarryStrandJamf]

This is fixed in version 1.3.2. It was kind of fixed in 1.3.1 but that had a regression.

[TimCraftA52]

For me this is still not fixed, just tried syncing to my NAS. Posix is fine, the ACL's did not come over or maybe were removed after the copy?

perry-1# ls -lde Slack_4.39.88.pkg -rwxrwxrwx + 1 A52\jamfadmin wheel 193810111 Jul 8 10:55 Slack_4.39.88.pkg OWNER: user:A52\jamfadmin GROUP: group:wheel CONTROL:dacl_auto_inherited,sacl_auto_inherited 0: SID:S-1-5-88-3-384 deny

Per the original post, I should be getting the two users added with the ACL as jamf admin would preserve. example below

perry-1# ls -ldea Slack_4.38.121* -rwxrwxrwx + 1 A52\jamfadmin wheel 192950416 May 13 15:57 Slack_4.38.121.pkg OWNER: user:A52\jamfadmin GROUP: group:wheel CONTROL:sacl_auto_inherited 0: user:A52\jamfclient allow file_gen_read 1: user:A52\jamfadmin allow file_gen_all