Automate Linux account provisioning as a reviewed change with a validated input file, explicit permissions and a verifiable result. A Bash loop does not make access decisions safe. Separate a read-only plan from account creation, and test both failure handling and repeat runs before allowing privileged changes.
Define the input contract
Start with approved identities and groups, an accountable requester and an expiry or review date. Use a simple documented format; do not evaluate input as shell code. Do not accept arbitrary sudo groups, home paths, shells or command fragments from an untrusted file. Keep credentials out of the manifest and logs.
The following Bash preflight accepts one proposed username per line, using a deliberately narrow naming policy. It checks syntax and duplicates only; it does not create accounts or certify that an identity is authorized.
#!/usr/bin/env bash
set -euo pipefail
export LC_ALL=C
if (( $# != 1 )) || [[ ! -f "$1" || ! -r "$1" ]]; then
printf 'Usage: bash preflight.sh readable-user-list\n' >&2
exit 2
fi
seen=("")
count=0
while IFS= read -r name || [[ -n "$name" ]]; do
[[ -z "$name" ]] && continue
if [[ ! "$name" =~ ^[a-z][a-z0-9_]{0,30}$ ]]; then
printf 'Rejected invalid username\n' >&2
exit 1
fi
for previous in "${seen[@]}"; do
if [[ "$previous" == "$name" ]]; then
printf 'Rejected duplicate username: %s\n' "$name" >&2
exit 1
fi
done
seen+=("$name")
count=$((count + 1))
done < "$1"
if (( count == 0 )); then
printf 'Rejected empty user list\n' >&2
exit 1
fi
printf 'Syntax accepted for %s proposed identities; no accounts changed.\n' "$count"Resolve identities before mutation
Check the target system's identity source and existing users, groups, UIDs and home ownership. An existing username may be locally managed or supplied by a directory service; do not silently overwrite it. Compare the full intended state and stop on conflicts. The useradd manual documents options and defaults, while usermod has different semantics for modifying existing accounts.
Make the apply phase explicit
Use a separate reviewed apply step that consumes the exact approved manifest. Specify required home, shell and group behavior; do not depend on unrelated host defaults. Quote arguments, avoid eval, stop on failed commands and record each completed change without secrets. Do not automatically delete earlier accounts when a later row fails: preserve the partial result for deliberate recovery.
Credential enrolment and any privileged access require their own approved process. For a fleet, an established configuration-management or identity platform may provide better state tracking than extending a one-off Bash script.
Test before running with privileges
- Missing, unreadable, empty and malformed input must fail without changes.
- Duplicate and conflicting identities must not be silently accepted.
- A repeated approved run must not unexpectedly reset credentials or memberships.
- A simulated partial failure must identify exactly which changes completed.
- The resulting account must perform its approved task and be denied unrelated access.
Keep the manifest, reviewed script version, execution result and access verification together. For the broader ownership and revocation process, see Linux account security. WebCare360 publishes this guide as a hosting provider; it does not promise custom provisioning automation as part of a service.
