chmod 550: Programs a Service Can Run but Cannot Change

550 separates two rights that people habitually give away together: the right to run something and the right to change it. A service account that is a member of the owning group can execute the script and read it, which an interpreter needs, and cannot modify it. A compromised service therefore cannot rewrite its own automation and wait to be run again.

The zero for others matters as much. Scripts leak: they contain hostnames, paths, account names, sometimes an inline credential that should not be there. At 555 or 755 every account on the machine can read all of that. At 550 only the group can, which shrinks the audience for an accidental disclosure to the set of accounts you deliberately chose.

Ownership is what makes it work. The file should be owned by a management account or by root, with the group set to the service, so that deployment changes it by temporarily relaxing the mode or by replacing it as the owner, while the running service never has write permission at all. Owner root with group set to the service account is the common shape.

On a directory, 550 gives the owner and the group the ability to list and traverse but not to create or delete entries. That is a useful pairing: a 550 directory of 550 scripts is a fixed set of fixed programs, where adding a new one is a deliberate administrative act rather than something the service can do to itself.

The trade off is deployment friction, and it is the point rather than a flaw. Any update has to be performed by the owner, which usually means a deploy step that runs as a different account from the service. If that feels awkward, the awkwardness is the security property showing up in the workflow.