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?
Question
CS6 Droplets
+3
+36How is this restriction being handled? We only restrict specific applications. Is there a way to "white list" a CS6 droplet?
+24Don, 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.
+3Sorry, 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.
+36How 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...
+3@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.
+1I 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.
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
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.