aws configure set can leave the credentials file empty: it is rewritten in place

[yottayoshida]

Describe the bug

aws configure set rewrites the whole shared credentials file in place. ConfigFileWriter.update_config in awscli/customizations/configure/writer.py opens it with open(config_filename, 'w'), which truncates it, and then writes the new contents (lines 114–115 on the v2 branch). If the write fails or the process is killed between the two, the file is left empty. Every profile in it is lost, not only the one being edited, and a secret access key cannot be retrieved again from IAM.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

After a failed or interrupted aws configure set, the credentials file holds either the old or the new contents.

Current Behavior

The file is 0 bytes, and aws configure get aws_access_key_id --profile default exits 1. When the write fails, the command prints [Errno 27] File too large and exits 255; nothing says that the other profiles are gone.

Reproduction Steps

export AWS_CONFIG_FILE=$PWD/config AWS_SHARED_CREDENTIALS_FILE=$PWD/credentials
printf '[default]\nregion = us-east-1\n' > config
printf '[default]\naws_access_key_id = EXAMPLE-ID-1\naws_secret_access_key = example-secret-1\n\n[work]\naws_access_key_id = EXAMPLE-ID-2\naws_secret_access_key = example-secret-2\n' > credentials
wc -c credentials    # 166
(ulimit -f 0; aws configure set aws_secret_access_key example-secret-3 --profile work)
wc -c credentials    # 0

ulimit -f 0 makes the write fail with EFBIG after the truncating open. A kill at the same point leaves the same result: strace -f -o /dev/null -P credentials -e inject=write:signal=KILL:when=1 aws configure set aws_secret_access_key example-secret-3 --profile work exits 137 with credentials at 0 bytes.

Possible Solution

Two directions, in increasing cost, and I have no stake in which: write the new contents to a temporary file in the same directory and os.replace() it over the original, keeping mode 0600; or keep the previous file until the new one is complete. The same function writes ~/.aws/config; only the credentials file was measured.

Additional Information/Context

Found with sideeye, a crash-consistency checker I maintain as a personal open-source project, with no commercial interest. It records the syscalls an operation makes in a directory, re-runs the operation killing the process before each one, and checks an invariant over the result — here, that both profiles' keys are still readable through aws configure get. On Debian's 2.23.6 the kill between the open and the write failed in 4 of 4 runs. Not measured: power loss, Windows, ~/.aws/config.

This issue was generated by AI tools, and reviewed by @yottayoshida. If you would rather not have tool-found reports here, say so and I will stop.

CLI version used

aws-cli/2.36.46 Python/3.14.6 Linux/6.12.76-linuxkit exe/aarch64.debian.13 (also aws-cli/2.23.6 from the Debian 13 package)

Environment details (OS name and version, etc.)

Debian 13 (trixie) in Docker, aarch64