Reset OSx Permissions to Default

Does not running Repair Permissions in Disk Utility take care of this? I know it will correct permissions on the system to the defaults, just not sure if that also applies to stuff in the /Applications path.

Have you tried that to see what it does?

No the Repair permissions via DU doesn't touch the files. I think the Repair permissions in DU repairs System Files

OK, makes sense.
Just curious, but are you running into problems with the permissions as they are? I'm just wondering what the impact of having permissions off is for you. Do the apps not launch or do they behave differently? I've seen applications set with "wrong" permissions before and usually it doesn't make any difference in how they work unless it was set to root and 700 or something like that.

As for correcting this in Composer, in the bottom right of the window there is a gear icon that will let you propagate the permissions down the folder structure of whatever is selected. I would use that to set everything to the most common and restrictive permissions all the way down and then work up to the higher level folders and files and set them accordingly( if they are in fact different permissions). That should cut some time down for you.

Again though, I would be interested to know the impact of the incorrect permissions and whether its even worth your effort to fix it.

I haven't seen issues as of yet, because the app(s) are not in production, I was just trying to keep permissions intact to ensure there won't be any issues. If there isn't an easy way to reset the permissions to what the OS originally sets the permissions as then I guess I will just move on. I just thought I would ask.

This is what I am trying to avoid....

Issues Related to Permissions
Incorrect permission settings may cause unexpected behavior. Here are several examples with troubleshooting suggestions:

Application installers, Applications folder
A third-party application installer incorrectly sets permissions on the files it installs, or even the entire Applications folder. Symptoms of the Application folder's permissions being set incorrectly include applications appearing in the dock as question marks, and/or not being able to connect to the Internet. It is also possible that software installed while logged in as one user will be inaccessible when logged in as another.

That is always a possibility with incorrect permissions, but just using the example iPhoto permissions you posted above, the POSIX perms on the incorrect bundle are set as wide open (777), so its unlikely the app wouldn't be readable. If anything. I'd say the danger would be that a non-admin user may be able to make modifications to or even delete items within the .app bundle when they shouldn't be able to.

That said, you can read POSIX permissions from a file or folder using stat-

stat -f%Mp%Lp "target"

You can try a loop like this to see if it will change the permissions of the new Composer resource target to the ones from the older version of your Composer resource.

#!/bin/sh

oldApp="/Library/Application Support/JAMF/Composer/Sources/iPhoto/ROOT/Applications/iPhoto-old.app"
newApp="/Library/Application Support/JAMF/Composer/Sources/iPhoto/ROOT/Applications/iPhoto-new.app"

find "$oldApp" -type f | while read file; do
    truePerms=$( stat -f%Mp%Lp "$file" )
    filePath=$( echo "$file" | awk -F"$oldApp" '{ print $NF }' )
    chmod $truePerms "$newApp$filePath"
done

Please be very careful with something like this though. I've only done a dry run of sorts by echoing back what it would do and not a real change permissions test, so I have no idea if it'll blow stuff up on your system.

You would also need to change this up to work on folders. The above will only target files (change -type f to -type d)

i also think chmod has the ability to copy permissions from one target and apply it to another, but I'm unsure of the syntax to do that. Guess what I'm saying is, there may be a much easier way to accomplish this, if its even necessary.

See these two articles for more info.

http://support.apple.com/kb/HT2963

http://support.apple.com/kb/HT1452?viewlocale=en_US&locale=en_US

That executable bit being set on non-executable files is really throwing me for a loop. If all you want is to remove write access for group and others:

sudo chmod -R go-w iPhoto.app

You could even get close to perfect for what you're after, but I can't figure out how to preserve executable access only on the executable files as well as the directories, I suppose you could manually go through and fix just the executables:

sudo chmod -R 0644 iPhoto.app
sudo chmod -R ugo+X iPhoto.app

Personally, I would just update the application on the one that has correct permissions using the normal update process, capture that. Delete and redeploy on the one with incorrect permissions. If the whole system is messed up, copy off data that you need, redeploy. Mass permissions problems like this are almost impossible to get 100% fixed and, if you're trying to use files to deploy to other machines, I wouldn't feel good about it unless I nuked the whole machine and started over. I re-image my packaging machine often.

@mm270

I've seen incorrect permissions cause some pretty annoying things before I caught the fact that I screwed them up in casper (during testing fortunately). It could be anything from the "are you sure you want to open this application that was downloaded from the internet" to users being unable to get past MS Office registration. Permissions issues 'can' be almost as bad as things can get.