Download Flgs, Xattr question

[Philsto]

Running into an issue where imaged laptops are displaying the "Are you sure you want to open this application downloaded from the Internet" Dialogue box with applications that have been added (Skype, Hipchat, etc). This is persistent in the user account, as the system thinks the main admin account has downloaded all the applications.

Found the following article, but it explained the way to disable the flag on one app:

https://jamfnation.jamfsoftware.com/article.html?id=59

I have also tried a few more scripts, all to no avail, as they seem to want to affect incoming downloads, not "existing" ones.

So here is the question. Do we need to be opening all apps in Composer before we package, and will this make a difference? (It seems all info for this stuff is captured in com.apple.quarantine, but not sure if this would be a part of the capture, i also would much rather the user plists are created fresh, although I suppose I could manually remove before packaging)

If not is there another workaround?

Also saw this, but that's a Safari attribute and isn't the same as the Xattr which controls the download flag, as far as I can tell.

https://jamfnation.jamfsoftware.com/viewProductFile.html?id=131&fid=514

Phil

[mscottblake]

During the package creation process, I add a postinstall script with the following code inside for problem apps.```
xattr -rd com.apple.quarantine "$3/Applications/application.app"

For example, if I'm packaging Firefox, I add this line into the postinstall:

xattr -rd com.apple.quarantine "$3/Applications/Firefox.app"
```

[Kumarasinghe · Accepted solution]

You have to make the root user as the application owner when you create the package.

1) Click on /Applications folder in Composer contents pane to highlight it.
external image link

2) Then click on Permissions icon.
external image link

3) Select "Apply Owner to Applications and All Enclosed Items".
external image link

Then create the package and see. This will fix your problem. Using this method for a long time.

Thanks

[mm2270]

So, if we're talking about simple application bundles, like Firefox, or other drag and drop style apps, then launching the app once under an admin account removes the quarantine flag. You can then wrap it up and you should be fine. However, its definitely good advice to check the owner/group and permissions on the app as well before building your package. This is an oft overlooked aspect when building Composer packages. While the app might not display the message anymore, generally speaking, they shouldn't be owned by anything other than root, just like in Kumarasinghe's image above.

As for your existing app rollouts, using msblake's script line should help you resolve these.

[mpermann]

@mm2270 and @kumarasinghe, so basically when you are packaging apps you always set the user permissions of the packaged app to root? What are you setting the group permissions to admin or wheel? Typically I use an admin account called staff to package apps with Composer. Most drag and drop apps have the user/group permissions set to staff(501) and admin(80). I typically leave the permissions set as they are and haven't run into any problems with apps working as expected. We only have two accounts on the vast majority of our computers, the hidden casper admin account and the end users account which is also an admin account. I don't know, maybe it's not best practice to have some apps with those permissions. I always find it useful to hear what others are doing and why they are doing it that way.

[mm2270]

I set mine to root:wheel as the owner:group, just because that's how the OS assigns the owner and group on core Apple apps, like TextEdit, Safari and such. Unless there's some reason not to set them that way, that's how I do it.

Truthfully though, as long as there are proper read permissions set on the app, for the group and world (everyone) , it should be fine. That said, some poorly designed apps require specific privileges to work right. I guess as long as you don't encounter any issues, no real reason to go through and fix anything

[Philsto]

So that did it, thanks all. Created a script with the xattr fix mentioned by msblake for the existing packages. However, for some reason Google chrome did not respond, even though I checked the app name, etc, etc...

So recreated the package again, this time making sure to propagate the owners permission downward, which did the trick. I think that's what bit us in the past, the permissions looked fine, but they weren't propagated.

[Kumarasinghe]

I normally leave them as root:admin as the owner and group. As per mm2270's comments you can leave them as root:wheel as the owner and group but there are some apps you need to give staff as the group instead of wheel. Have a look when you are about to package them and test it properly.

[donmontalvo]

Packages.app follows Apple's guidelines for owner:group and permissions, but lets you alter if you like. So no need to sweat those details:

http://s.sudre.free.fr/Software/Packages/about.html

I wouldn't suggest changing permissions on any default OS X folders like /Applications. Instead I would manage ownership and permissions on the stuff you're packaging for deployment.

Don

[Kumarasinghe]

I wouldn't suggest changing permissions on any default OS X folders like /Applications. Instead I would manage ownership and permissions on the stuff you're packaging for deployment.

@donmontalavo
That's exactly what we are doing.
We are not changing any permissions on any default folder like /Applications.
What we are doing is changing the permissions of the app accordingly.

[donmontalvo]

@Kumarasinghe My apologies, I misunderstood. :) Packages.app will set proper owner/permissions when deploying to the default OS X folders, so it's a step we never have to worry about.

[Kumarasinghe]

No problems Don. I respect your opinion and your experience.

[tkimpton]

Me too, been doing it like that for years