Permissions, Ownership, and Atomic File Updates

1. Permission bits describe owner, group, and others

ls -l app.conf
chmod u=rw,g=r,o= app.conf

2. Numeric modes encode permission combinations

chmod 0644 app.conf
chmod 0755 deployctl

3. umask affects defaults for newly created objects

old_umask=$(umask)
umask 077

secret=$(mktemp)
printf 'secret\n' > "$secret"

umask "$old_umask"

A restrictive umask is useful around sensitive temporary state.

4. Ownership changes cross a privilege boundary

chown appuser:appgroup app.conf

Changing ownership typically requires suitable privileges. Scripts should not silently assume sudo or automatic elevation.

5. Recursive metadata changes need separate file and directory policy

find app-tree -type d -exec chmod 0755 {} +
find app-tree -type f -exec chmod 0644 {} +

One recursive mode applied indiscriminately to both files and directories can break functionality or expose content.

6. Metadata is part of deployment correctness

Modes, ownership, timestamps, ACLs, extended attributes, and security labels may matter just as much as file bytes. Copy tools preserve different metadata depending on options and platform.

7. Build and validate before replacing live content

flowchart TD
  A["create temp in target dir"] --> B["render"]
  B --> C["validate"]
  C --> D["set metadata"]
  D --> E["rename into place"]

target="./app.conf"
dir=$(dirname -- "$target")
tmp=$(mktemp "$dir/.app.conf.XXXXXX") || exit 1

if render_config >"$tmp" &&
   validate_config "$tmp"; then
  chmod 0644 -- "$tmp"
  mv -- "$tmp" "$target"
else
  status=$?
  rm -f -- "$tmp"
  exit "$status"
fi

Creating the temp file in the destination directory makes same-filesystem rename behavior much more likely.

8. Atomic rename is not the same as crash durability

A same-filesystem rename commonly gives atomic pathname replacement: readers see old or new content rather than a half-written file. Power-loss durability involves filesystem and fsync semantics that Bash alone does not guarantee.

9. Decide whether the deployment owns a symlink or its target

if [[ -L $target ]]; then
  printf 'refusing symlink replacement without explicit policy\n' >&2
  exit 1
fi

Replacing a link, following it, and replacing its target are distinct operations.

10. install can set mode during deployment

install -m 0644 -- rendered.conf "$target"

For simple installs this is clear and concise. For atomic promotion, stage in the destination filesystem and rename deliberately.

11. Hands-on lab: validated atomic-style update

mkdir -p "$HOME/devops-academy/bash/chapter09/lesson05"
cd "$HOME/devops-academy/bash/chapter09/lesson05"

target="app.conf"
printf 'version=1\n' > "$target"
chmod 0644 -- "$target"

dir=$(dirname -- "$target")
tmp=$(mktemp "$dir/.app.conf.XXXXXX") || exit 1

cleanup() {
  [[ -n ${tmp:-} && -e $tmp ]] && rm -f -- "$tmp"
}
trap cleanup EXIT

cat > "$tmp" <<'EOF'
version=2
environment=staging
EOF

if grep -q '^version=2$' "$tmp" &&
   grep -q '^environment=staging$' "$tmp"; then
  chmod 0644 -- "$tmp"
  mv -- "$tmp" "$target"
  tmp=""
else
  printf 'validation failed\n' >&2
  exit 1
fi

ls -l "$target"
cat "$target"

12. Knowledge check

13. Summary

Reliable file deployment includes permissions, ownership, and update semantics. Use explicit metadata policy, restrictive defaults for secrets, validated same-filesystem promotion, and distinguish pathname atomicity from crash durability.

14. Further reading

• GNU Coreutils manuals — chmod, chown, install, mv.
• GNU Bash Reference Manual — umask.
• POSIX permission and rename semantics.
• Linux manual pages — rename(2), chmod(2), chown(2), fsync(2).