chmod 664: Group Writable Files for Shared Work

664 is what a shared document should be. The owning group edits it, everyone else reads it, and nobody outside can change it. Paired with a 2775 directory so that new files inherit the right group, it gives a team a workable shared area without anyone needing to widen anything later.

It is also a default in disguise. Distributions that use per-user private groups set a umask of 002, which produces 664 for new files and 775 for new directories. Because each user's primary group contains only that user, the group write bit is harmless until a file is deliberately moved into a shared group, at which point collaboration works without a chmod.

The others read bit is worth a deliberate thought. Every local account, including service accounts, can read this file. That is fine for documentation, source code on a private build machine or shared data, and wrong for anything with a credential in it, where 660 or 640 is the correct choice depending on whether the group needs to write.

On a directory 664 does not work, because the execute bit is missing and nothing can traverse in. Shared directories want 775 or 2775. This is the single most common recursive chmod accident: applying a sensible file mode to a whole tree and finding every directory has become unusable.

The security question, as with 775, is about the group rather than the digits. 664 owned by a two person project group is tight. 664 owned by a group that most of the machine belongs to is effectively 666 with extra steps, and should be narrowed to a purpose built group.