DongHyeonkaandClaude Opus 5
b2963105a8
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
114 lines
5.6 KiB
Markdown
114 lines
5.6 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: analysis-finding-a08-f004
|
|
title: 발행 rename만 경로 기반이고, 그것을 지키는 것은 이 모듈이 "근사에 불과하다"고 적은 사전검사다
|
|
topic: file-transfer-and-storage
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: case:analysis-finding-a08-f004
|
|
evidenceCapturedOn: 2026-09-01
|
|
body: case-analysis-finding-a08-f004.body.md
|
|
assets:
|
|
- key: analysis-finding-a08-f004
|
|
file: ../../../final/evidence/rendered/analysis-finding-a08-f004.svg
|
|
evidence:
|
|
- ../../../final/evidence/raw/analysis-finding-a08-f004.txt
|
|
source:
|
|
- 원본 분석 절은 analysis/08-adapter-outbound-fileserver.md#L376 이다.
|
|
---
|
|
|
|
# 발행 rename만 경로 기반이고, 그것을 지키는 것은 이 모듈이 "근사에 불과하다"고 적은 사전검사다
|
|
|
|
이 모듈은 디스크립터를 따라 내려가는 방식으로 심볼릭 링크 공격을 구조적으로 막는다. 콘텐츠를 보이게 만드는 마지막 단계만 경로 기반으로 남아 있고, 그 단계를 지키는 사전검사는 모듈 자신이 근사에 불과하다고 적어 둔 메서드다.
|
|
|
|
## 관계
|
|
|
|
- **검사를 더 하는 것은 창을 좁힐 뿐 닫지 않는다**
|
|
이 사례가 그 규칙의 형태다.
|
|
- **두 selector의 설정 취급이 비대칭이고 검증된 쪽은 하나뿐이다**
|
|
같은 리프의 다른 사례다.
|
|
- **계측 필드가 자기 회귀 test를 지목하는데 그 test가 읽지 않는다**
|
|
같은 리프의 문서 결합 사례다.
|
|
|
|
## 문제
|
|
|
|
이 모듈의 지역 플랫폼에 남은 파일 시스템 정적 호출을 전수 조사했다.
|
|
|
|
대부분은 정당하다. 루트 열기는 문서가 피할 수 없는 하나의 경로 해석이라고 적은 것이고, 시작 시 능력 탐침은 격리된 영역에서 돌며, 고아 검사와 상태 조회와 사용량 탐침은 다른 하위 범위다.
|
|
|
|
## 결론
|
|
|
|
문제는 쓰기 경로에 남은 다섯 호출이다.
|
|
|
|
원자적 이동 발행자의 발행 이동과 그 실패 분류를 위한 존재 검사 둘, 발행 검증의 크기 조회, 메타데이터 포인터 발행자의 준비 파일 삭제다.
|
|
|
|
그중 발행 이동이 핵심이다.
|
|
|
|
발행자는 그 이동 직전에 루트와 대상 부모 사이에 심볼릭 링크가 없는지 검사한다. 경로 기반 사전검사다.
|
|
|
|
그런데 그 메서드의 자바독이 스스로를 이렇게 설명한다.
|
|
|
|
능력 탐침을 위해 남겨 두었으며 탐침은 여전히 경로명으로 추론한다. production 접근은 더 이상 여기에 의존하지 않는다. 디스크립터를 하나씩 따라 내려가며 링크를 따르지 않는 방식이 심볼릭 링크 성분을 구조적으로 거부하고, 사전검사는 그것을 근사할 수 있을 뿐이라는 것이다.
|
|
|
|
즉 production 이 더 이상 의존하지 않는다고 적힌 메서드를, 콘텐츠를 보이게 만드는 바로 그 단계가 유일한 보호로 쓴다.
|
|
|
|
같은 모듈의 다른 문서가 겨냥한 패턴 그대로다. 검사를 더 하는 것은 창을 좁힐 뿐 닫지 않는다는 문장이다.
|
|
|
|
같은 불일치가 파일 길이 조회에서도 보인다.
|
|
|
|
판정은 P3 다.
|
|
|
|
실제 악용에는 저장소 루트 안쪽 쓰기 권한이 필요하다. 이 리프가 그 루트의 소유자와 권한을 증명하는 것은 현재 경로뿐이고, 플랫폼 저장소 루트의 증명은 부트스트랩의 시작 검증기 몫이다.
|
|
|
|
그래서 도달성은 배포 형상에 달려 있다.
|
|
|
|
그럼에도 기록하는 이유는 모듈 자신의 문서가 이 패턴을 명시적으로 불충분하다고 선언했다는 점이다.
|
|
|
|
수정은 발행 이동을 디스크립터 기반 도우미로 옮겨 부모 서술자 상대 이동을 쓰고, 크기 조회를 채널의 속성 읽기로 바꾸는 것이다.
|
|
|
|
## 검증 환경
|
|
|
|
OpenJDK : 21.0.12
|
|
확인 방식 : 정적 호출 전수 조사와 자바독 대조
|
|
소스 수정 : x
|
|
|
|
## 재현 조건
|
|
|
|
원문은 final/evidence/raw/145 계열에 있다.
|
|
|
|
1. 지역 플랫폼의 파일 시스템 정적 호출을 전수 조사한다.
|
|
2. 각 호출이 어느 경로에 속하는지 분류한다.
|
|
3. 쓰기 경로에 남은 호출을 추린다.
|
|
4. 발행 이동 직전의 사전검사가 무엇인지 확인한다.
|
|
5. 그 사전검사 메서드의 자바독을 읽는다.
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
발행 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`로 바꾸는 것이다.
|
|
|
|
## 확인하지 못한 것
|
|
|
|
심볼릭 링크를 실제로 심어 발행 단계를 통과시키는 재현을 하지 않았다. 그것은 저장소 루트 안쪽 쓰기 권한을 전제한다.
|
|
|
|
<!-- body:end -->
|