Recommended Permissions for files in Composer packages

[nigelg]

Hi all,

I have recently hit a strange issue where packages created in composer have refused to install via policy because the jamf binary is unable to access the file copied to the jamf cached folder.

I am able to get round this issue by changing the permissions on the files within the package to be owned by root with the group as admins and 755 permissions.

However, my understanding was that the files within the packages needed to be set up correctly for the system to run them and most of the default applications in my application folder are root:wheel rather than root:admins. But root:wheel packages aren't able to be installed - they error.

I can write a script to change the permissions after installation but is this step necessary? Does anyone else have any tips regarding permissions in Composer packages and what permissions have to be on the files for the jamf binary to be able to install them?

I might also add something that doesn't make much sense. These packages did install when I created them originally in an earlier version (could have been 9.2) but I ran remote from a different machine and created policies on a different machine to the one I used the other day when I had this problem. I am currently on 9.24, upgrading to 9.25 later today.

[franton]

My golden rules of snapshot packaging are:

1) Snapshot package on a computer without antivirus and as few other apps as possible!
2) Apps that live in /Applications should be root:admin with 755 permissions.
3) Apps that live in ~/Applications/ should be the same as the user they're being installed for.
4) If your app has an installer .pkg, it's worth giving that a try before going to snapshot.

Works for me ;)

[nigelg]

Thanks - that backs up what I have found so far. Would you treat preferences any differently? I really like that I can set the preferences to be written to the template and to users that already have home directories. Does Casper do the magic so an admin preference with owner root:admin is converted to the users name and group ownership?

[franton]

Anything that goes to user template and existing user preference folders can be safely ignored. It appears that the install process compensates for it.

[jhalvorson]

@franton, about rule number 2. I've noticed that the apps that live in /Application by Apple and some others are set to root:wheel. I usually set the apps to wheel and it's been working. Is there a reason to go with admin instead of wheel?

[franton]

@jhalvorson Not really. It's just worked for me consistently so it's what I do.

[chris_kemp]

@jhalvorson, I think it's really a semantic difference. Since the group & all permissions are set the same (in this case to 5, read + execute) then it really doesn't matter that much. Since the owner (root in the above example) is the only one with write permissions then root is the only one who can change/delete the app or its contents (assuming the permissions are applied down through the app).

[dgreening]

I definitely use root:wheel for my Composer packages, and have had no problems doing so.

[nigelg]

The error I had was "Error: An error occurred attempting to mount the package "<nameofpackage>" when the permissions were set to root:wheel inside the package.

This discussion suggests that the permissions should be set to 755 before uploading to Casper admin but doesn't mention the files within the package, rather the package itself. So what needs to be set to 755, the internal files, the actual package or both?

https://jamfnation.jamfsoftware.com/discussion.html?id=7758

[nigelg]

I have been able to get packages that failed to install working by changing their permissions on the share to 755. Not sure where it got messed up. The permissions changed somewhere along the line so I will have to keep an eye on that. I didn't need to change permissions inside the package to get them to install.

[systems_support]

I just recently started seeing error: "An error occurred attempting to mount the package" for the first time. I tried the chmod command and tried rebuilding the package to no avail. Then I noticed all of the failed policies were on machines that were updated to 10.11.5 (latest version of El Capitan) but had not rebooted since getting 10.11.5. Once I rebooted the machines, the policy worked fine.