CS6 Droplets

kschlatter
New Contributor

Most of our creative team that have CS6 are not local admins. We restrict applications from running from most locations except the applications folder which has the side effect of not allowing droplets to run. Does anyone have a workaround for this?

8 REPLIES 8

donmontalvo
Esteemed Contributor III

How is this restriction being handled? We only restrict specific applications. Is there a way to "white list" a CS6 droplet?

--
https://donmontalvo.com

mm2270
Legendary Contributor III

Don, I think the OP probably has the MCX com.apple.applicationaccess.new setting applied to create blacklist and whitelist locations for disallowing/allowing apps to launch from specific paths. If you add /Users/ into the blacklist, anything from the Desktop won't run, such as those droplets.

@kschlatter, I dont believe there's an easy answer here. You can set up a whitelist location in the /Users/ space, but that would mean any app they copy into it would be allowed to launch. If you're talking about creative users, I suspect they will figure out that loophole pretty quickly and start exploiting it.

The only workaround I can think of would be to set up a script to locate CS6 droplet apps on their Desktop, then copy them into a location within /Applications/, like /Applications/Droplets/ that is not writable to the users, but would be in the whitelisted path. They could run it from Self Service every time they create a new droplet and it would move them into that directory from ~/Desktop. As a bonus, you might be able to script it to create an alias or symlink back to their Desktop from the /Applications/Droplets folder so they would have easy access to it (or they could do it themselves). Though I actually don't know for sure if an alias would be allowed to launch from Desktop either, even if the original .app is in /Applications. You'd need to test that.
Also, I assume CS6 droplets would be identifiable in some manner from regular .apps, such as the bundleID they get created with or something along those lines. Some check you could put in the script that would only grab those droplets and not just any .app lying around on the user's Desktop.

kschlatter
New Contributor

Sorry, yes we are using the whitelist to specify locations that applications that can launch. I couldn't come up with any location that would work without them quickly figuring out that they could launch any app from that location. The self-service move script sounds like a potential fix. I'm sure not as easy as the creatives would like, but should cover both sides. Let me get that tested and we'll let you know how it goes. Thanks for the quick response.

donmontalvo
Esteemed Contributor III

How about a process where a droplet is sent to you to package/deploy using Self Service? Then it can be installed into /Applications and users can launch? This way it's installed without needing admin rights and users can launch? Should be easy to set up a packaging workflow to drop whatever they give you into a wrapper package and upload to JSS...

--
https://donmontalvo.com

kschlatter
New Contributor

@don Potentially, they could be working on time constraints. If this is an after hours issue, I would hate to have an on call person have to do this at any time. I was hoping that we could build a library of droplets that they could use, but my understanding is that they are pretty much custom for each use and not able to be edited once created. The self-service script allows them to process a droplet at any time which would be nice.

kdavies
New Contributor

I ended up writing this, putting it into Self Service and instructing users to save droplets to their Desktop

find /Users//Desktop -name ".app" -print0 | xargs -0 -I {} grep -l com.adobe.photoshop.droplet {}/Contents/Info.plist | sed -E 's//Contents/Info.plist//' | xargs -I {} mv '{}' /Applications

It's then copied into /Applications where the user can run it.

tkimpton
Valued Contributor II

That is awesome. Thanks it's good to know this as I restrict apps and am close to rollout.

One thing I would do in the script is to change permissions on the moved droplet because of desk sharing.

Not sure how I would add it in though

kdavies
New Contributor

Our machines are 1:1 so that wasn't really something we considered.