DongHyeonkaandClaude Fable 5.1
b25357c48a
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다 - 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5 (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를 techviz 로 만들었다 - 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs 돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다. Concept 이 인용한 코드가 SSOT 에 없어 뺐다 - candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
5.6 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, body, assets, evidence, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | body | assets | evidence | source | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | analysis-finding-a08-f004 | 발행 rename만 경로 기반이고, 그것을 지키는 것은 이 모듈이 "근사에 불과하다"고 적은 사전검사다 | file-transfer-and-storage | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:analysis-finding-a08-f004 | 2026-09-01 | case-analysis-finding-a08-f004.body.md |
|
|
|
발행 rename만 경로 기반이고, 그것을 지키는 것은 이 모듈이 "근사에 불과하다"고 적은 사전검사다
이 모듈은 디스크립터를 따라 내려가는 방식으로 심볼릭 링크 공격을 구조적으로 막는다. 콘텐츠를 보이게 만드는 마지막 단계만 경로 기반으로 남아 있고, 그 단계를 지키는 사전검사는 모듈 자신이 근사에 불과하다고 적어 둔 메서드다.
관계
- 검사를 더 하는 것은 창을 좁힐 뿐 닫지 않는다 이 사례가 그 규칙의 형태다.
- 두 selector의 설정 취급이 비대칭이고 검증된 쪽은 하나뿐이다 같은 리프의 다른 사례다.
- 계측 필드가 자기 회귀 test를 지목하는데 그 test가 읽지 않는다 같은 리프의 문서 결합 사례다.
문제
이 모듈의 지역 플랫폼에 남은 파일 시스템 정적 호출을 전수 조사했다.
대부분은 정당하다. 루트 열기는 문서가 피할 수 없는 하나의 경로 해석이라고 적은 것이고, 시작 시 능력 탐침은 격리된 영역에서 돌며, 고아 검사와 상태 조회와 사용량 탐침은 다른 하위 범위다.
결론
문제는 쓰기 경로에 남은 다섯 호출이다.
원자적 이동 발행자의 발행 이동과 그 실패 분류를 위한 존재 검사 둘, 발행 검증의 크기 조회, 메타데이터 포인터 발행자의 준비 파일 삭제다.
그중 발행 이동이 핵심이다.
발행자는 그 이동 직전에 루트와 대상 부모 사이에 심볼릭 링크가 없는지 검사한다. 경로 기반 사전검사다.
그런데 그 메서드의 자바독이 스스로를 이렇게 설명한다.
능력 탐침을 위해 남겨 두었으며 탐침은 여전히 경로명으로 추론한다. production 접근은 더 이상 여기에 의존하지 않는다. 디스크립터를 하나씩 따라 내려가며 링크를 따르지 않는 방식이 심볼릭 링크 성분을 구조적으로 거부하고, 사전검사는 그것을 근사할 수 있을 뿐이라는 것이다.
즉 production 이 더 이상 의존하지 않는다고 적힌 메서드를, 콘텐츠를 보이게 만드는 바로 그 단계가 유일한 보호로 쓴다.
같은 모듈의 다른 문서가 겨냥한 패턴 그대로다. 검사를 더 하는 것은 창을 좁힐 뿐 닫지 않는다는 문장이다.
같은 불일치가 파일 길이 조회에서도 보인다.
판정은 P3 다.
실제 악용에는 저장소 루트 안쪽 쓰기 권한이 필요하다. 이 리프가 그 루트의 소유자와 권한을 증명하는 것은 현재 경로뿐이고, 플랫폼 저장소 루트의 증명은 부트스트랩의 시작 검증기 몫이다.
그래서 도달성은 배포 형상에 달려 있다.
그럼에도 기록하는 이유는 모듈 자신의 문서가 이 패턴을 명시적으로 불충분하다고 선언했다는 점이다.
수정은 발행 이동을 디스크립터 기반 도우미로 옮겨 부모 서술자 상대 이동을 쓰고, 크기 조회를 채널의 속성 읽기로 바꾸는 것이다.
검증 환경
OpenJDK : 21.0.12 확인 방식 : 정적 호출 전수 조사와 자바독 대조 소스 수정 : x
재현 조건
원문은 final/evidence/raw/145 계열에 있다.
- 지역 플랫폼의 파일 시스템 정적 호출을 전수 조사한다.
- 각 호출이 어느 경로에 속하는지 분류한다.
- 쓰기 경로에 남은 호출을 추린다.
- 발행 이동 직전의 사전검사가 무엇인지 확인한다.
- 그 사전검사 메서드의 자바독을 읽는다.
본문
발행 rename만 경로 기반이고, 그것을 지키는 것은 이 모듈이 "a precheck could only ever approximate"라고 적은 사전검사다.
LocalPersistentRootAttestor 참조 위치
:::evidence key="analysis-finding-a08-f004" alt="코드베이스에서 LocalPersistentRootAttestor 를 검색한 출력 9줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="LocalPersistentRootAttestor 코드베이스 검색 — 9줄 · exit 0" zoom="true" :::
도달성이 배포 형상에 달려 있다
실제 악용에는 스토리지 루트 안쪽 쓰기 권한이 필요하고, 이 leaf가 그 루트의 소유자·권한을 증명하는 것은 R2 경로(LocalPersistentRootAttestor)뿐이며, 플랫폼 저장소 루트의 증명은 app-bootstrap의 startup validator 몫이다. 심각도를 P3로 두는 이유가 그것이다.
그럼에도 기록하는 이유
모듈 자신의 문서가 이 패턴을 명시적으로 불충분하다고 선언했다.
수정
발행 rename을 SecureDirectoryWalk.inParentOf로 옮겨 부모 서술자 상대 move를 쓰고, sizeOf를 channels.readAttributes로 바꾸는 것이다.
확인하지 못한 것
심볼릭 링크를 실제로 심어 발행 단계를 통과시키는 재현을 하지 않았다. 그것은 저장소 루트 안쪽 쓰기 권한을 전제한다.