Rummaging around some directories using Terminal on my OS X machine, I've discovered that many files (mostly old .doc, .xls, .jpg and even some .url files) have permissions
-rwx------+
rather than the more common (and expected)
-rw-r--r--+
or
-rw-r--r--@
I'm unclear why this should be the case. Most of the offending files are older (some quite old, perhaps from the dark days when they resided on a Windows machine) and there have been many migrations and updates since their creation. So,
- is there any obvious or common cause — or possibly legitimate reason — for large numbers of (generally older) files having these permissions, and
- is there any reason I should worry that they are executable?
I assume if the answer to 2 is yes, I can simply locate the offending files and chmod a-x.
- is there any obvious or common cause — or possibly legitimate reason — for large numbers of (generally older) files having these permissions, and
Yes, FAT doesn't have any notion of permissions, so files copied via a FAT volume (which is how many USB sticks and SD cards are formatted) frequently have permissions -rwx------. SMB also doesn't support Unix style permissions, unless using Unix extensions, so files copied that way can also end up with such permissions.
- is there any reason I should worry that they are executable?
For the most part, no. It's possible that if you had them in your PATH, and they had a name that shadowed some command you were using, and they were a polyglot document that also functioned as an executable, something nefarious could happen. These conditions are unlikely to arise, but if you're worried, feel free to fix the permissions as you describe.
I, too, have found that the translation from Windows' ACLs to OSX's BSD permissions can sometimes go awry. If it's not going to be executed (i.e., if it's a plain file such as an image) there's no reason not to unset the executable bit. Directories, of course, need that bit set for you to cd into them.
One other thing to look at: if the files are mounted on a remote volume via samba you might also see this happening. In that case, the permissions are related to how the volume is mounted, not to the files themselves.
