File permissions

When you will meet it

Two frequent scenes. One: a downloaded script answers "./run.sh: Permission denied" — usually not missing authority but a missing execute bit, one chmod away. Two: SSH keys and .env files with permissions too loose get flatly refused by SSH or leaked outright. Agent sandboxes that promise "these folders are writable" are built on this same machinery.

Minimal example

echo 'echo hello' > demo.sh
ls -l demo.sh        # -rw-r--r--：能讀能寫，沒有 x（執行）
./demo.sh            # permission denied
chmod +x demo.sh     # 加上執行權限
./demo.sh            # hello
rm demo.sh           # 清理掉

The first ten characters of ls -l are the permissions: a file-type marker, then three rwx triples for owner / group / others, where a dash means denied. r = read, w = modify, x = execute (for folders: may enter). chmod 600 — only the owner reads and writes — is the standard for .env files and SSH private keys.

What people get wrong

• Answering every "Permission denied" with sudo. Read the ls -l output first: usually the file lacks x or you are not the owner — chmod and chown are the cure. Escalating skips the symptom and buries the cause.
• Using chmod 777 to "fix" permission problems for good. That lets every program — including any agent you run — modify the file, and SSH outright refuses private keys that are too open. Too tight causes errors; too loose causes incidents.