CrownyDoc 문서함 견적서 제안서 도면 + 새 문서 문서편집기 프로젝트문서 기술백서

← 목록

기타 2026-07-24 11KB 읽기 11분

크라우니클라우드 업그레이드 — 현황분석 + 작업목록

개요

cloud.crowny.org:9611 업그레이드 준비를 위한 현황파악·분석·작업목록. 아울러 오라클클라우드 가입 시 "인증되지 않은 브라우저" 차단을 크라우니AI UA 수정으로 해소(별건, 완료).

핵심 발견 — 이원화(SSOT 혼란)

크라우니클라우드가 두 개 존재:

(A) /Users/ef/crowny-cloud/ — 순수 Node 프로토타입(server.js, 기본 PORT 9945). 한선/·routes/·tools/ 전부 빈 디렉토리, 블롭판정.한선은 server.js에서 호출 0(스텁). 미가동·방치(7/5~12). ⚠️ 9945는 chess.crowny.org와 충돌.
(B) 실운영 = crowny-services/서비스서버.한선(1148줄) → crownyc 컴파일 서비스서버.toau → SERVICE=cloud PORT=9611로 구동. 29개 서비스가 공유하는 단일 바이너리. blob은 한선씨 VM 네이티브 opcode(857 버퍼파일쓰기·858 버퍼SHA256·859 파일소켓범위전송). v1.0 출시(7/7) 이력 보유.

→ 업그레이드 정본은 (B). (A)는 삭제 또는 문서화로 혼선 제거.

실측 사실

실프로세스: crownyc run 서비스서버.toau (+ 병행 node 서비스서버.js). 통합매니저가 자가치유.
인증: X-Crowny-Owner 헤더 = 계정(무헤더 거부, 임의 8~100자 토큰이면 quota 통과). 무비밀번호 bearer 모델 실증.
데이터: crowny-services/data blobs 10M(오너10)·anchor 60K(해시체인)·merge 180K. 테스트 잔존 다수.
백업/복원 로직 없음(디스크 영속 의존).
소비처: crowny-ai(engine/cloud-connect.js·widget-cloud.js)·chansong — API 변경 시 동반 수정.
vps:9618(멀티클라우드 관제)는 무관 별건(이름만 겹침).
RCE 이력: 서비스서버.한선:366-386 — 07-09 owner 셸탈출 RCE 수정(화이트리스트). 잔존: /api/share 토큰은 길이만 검사, 체계("rm -f…") 결합부에 owner식 화이트리스트 미적용(:895,937). 현재 파일존재 게이트로 실악용은 차단이나 방어심층 위반.

작업목록 (우선순위)

P0 (보안·SSOT — 업그레이드 전 선결)

SSOT 확정: (A) 삭제/아카이브 + (B)를 정본 선언. (A) 빈 디렉토리·9945 충돌 위험 제거.
/api/share 토큰 화이트리스트: owner와 동일한 영숫자·_·- 강제(서비스서버.한선:895,937 체계 결합부). 방어심층.
인증 강화 설계: 무비번 bearer → 실인증(비번/세션/2FA) 도입 방안. 실사용자 확대 전 필수. 기존 토큰 하위호환 마이그레이션 포함.

P1 (기능·운영)

API 스펙 정본화: (A) /api/blob?o=&id= vs (B) /api/blob/upload/<owner> 불일치 정리. crowny-ai·chansong 커넥터 기준 확정.
백업/복원: 스냅샷 회전 + 오프사이트 백업 설계·구현(현재 부재).
데이터 정리: merge의 SQLi 페이로드 파일명·test-verify/guardtest 잔존물 청소 + 파일명 생성경로 인젝션 재스캔.
배포 체크리스트: 서비스서버.toau 29서비스 공유 → cloud 개별 재기동 안전하나 회귀범위=전체 명시.

P2 (확장)

청크 프로토콜 정식화: VM 문자열 65535B 캡·게이트웨이 본문 24KB 제한 → 대용량 업로드 청킹.
쿼터/과금 연동: pay(맘/포네) 연계 유료 플랜 검토.
오피스/앱 연동 확대(7/20 오피스 연동 기반).

오라클 브라우저 차단 (별건 — 완료)

원인: 크라우니AI 신셸이 UA 미설정 → WKWebextbf 기본 UA에 Version/x Safari/x 토큰 부재 → 브라우저 화이트리스트 탈락.
수정: crowny-ai-content.m 웹뷰 2곳(makeWebView·팝업)에 Safari 17.5 파리티 UA. 재빌드·설치·실측(메인 재확인) 통과.
⚠️ 사용자 라이브 인스턴스는 재시작해야 새 UA 적용(디스크 바이너리만 교체됨).
상세=2026-07-24-crownyai-safari파리티UA-갭검증엔진전환.md

P0 완료 (2026-07-25)

①SSOT: crowny-cloud 죽은파일 _방치아카이브_2026-07-25/로 이동, takeurban프록시(라이브) 보존, README 명시. 정본=서비스서버.한선:9611.
②share 화이트리스트: 토큰유효() [a-zA-Z0-9_-]24~128, share 2곳 적용. STRICT컴파일·cloud단독재기동·악성토큰(셸주입·traversal) 400 실측·29서비스 온전. 백업 .bak-share화이트리스트.
③실인증: 3단계 마이그레이션 설계 완료(별도문서 2026-07-25-크라우니클라우드-실인증-설계). 구현은 결정①②선행.

P1 진행 (2026-07-25~26)

④ API정본화: 완료(문서 2026-07-25-크라우니클라우드-API정본-v1). ★기능버그 3건 발견(수정대기): (1)파일목록 클라가 /api/files 호출→실경로는 /api/merge?key=cloud_items_v1 (2)ZIP·share-blob 501스텁 항상실패 (3)merge 가짜LWW(items 미반환·last-POST-wins).
⑦ 배포체크리스트: /Users/ef/crowny-services/배포체크리스트.md 완료.
⑥ 데이터정리: 정크 3.5MB→data/_격리_2026-07-25/ 가역아카이브(정상키·실사용자 보존). ★인젝션 재스캔이 RCE 2건 발견.
⑤ 백업: 설계완료(2026-07-25-백업설계-P2프레이밍). 구현대기(로컬스냅샷+GFS회전, 오프사이트=결정필요).

★P0급 긴급수정 (P1-⑥ 부산물, 2026-07-26)

crowny-services 셸주입 RCE 2건 수리(owner07-09·share07-25와 동형):

A blob sha256(무인증 공개 GET·무따옴표 체계 wc) → blob해시안전() 길이64+소문자hex. 실 RCE 차단.
B merge 키($() 명령치환) → 키유효() [a-zA-Z0-9_-].

STRICT컴파일·cloud단독재기동(81377→61052)·악성입력 400·프로브 미생성·29서비스 온전. 무방어 체계( 지점 0. 학습=feedback_crowny_services_체계_셸주입_반복패턴.

★기능버그 3건 수정 완료 (2026-07-26 — 사용자 지정 우선)

④에서 발견된 라이브 기능결함 3건 전부 실구현(정직차단 0):

BUG1 파일목록: 서버 /api/files 신설(merge cloud_items_v1→{items:[...]} 순수배열, 이중중첩 해소). 소비처 cloud-connect.js 오별칭 교정.
BUG2 ZIP·blob공유: blob-share POST/GET 실구현(note패턴+blob Range opcode856/859 재사용), ZIP=zip CLI shell-safe 실구현(입력 전량 화이트리스트). 둘 다 501 탈출.
BUG3 merge 真LWW: id별 최신ts 병합+deleted 툼스톤+items 응답, 구형식 하위호환.

STRICT컴파일·cloud단독재기동(61052→11638)·검증(BUG3 6/6·RCE회귀0·소비처 byte-identical). 문서=2026-07-26-크라우니클라우드-기능버그3건-수정.

종합 상태 (2026-07-26)

P0 ①②③ 완료(③ 설계). P0급 RCE 2건(blob·merge) 수리. P1 ④⑥⑦ 완료·기능버그3건 완료. ⑤ 설계완료·구현대기. P2 ⑧⑩ 대기(④기반), ⑨ 사용자 보류.

P1-⑤ 백업 완료 (2026-07-26)

도구: 크라우니클라우드백업.sh(snapshot/verify/list/rotate/cycle/restore) + 백업회전.한선(GFS 일7·주4·월6, STRICT0) + LaunchAgent org.crowny.cloudbackup(6h, cycle). 첫 스냅샷 3.8M×2, verify blob 재해시 17/17 PASS, restore dry-run 무해, 라이브 무영향.
★verify가 라이브 데이터 손상 발견(도구가 제 역할): anchor 해시체인 파싱불가 — anon 테스트/퍼즈 오너 2개(anon_2b31...:26줄, anon_mrvzk33...=⑥ SQLi퍼즈오너). 실사용자 아님·서비스 정상. 해시체인 복구=별도 신중작업(후속).
오프사이트 복제=결정 대기(설계 결정A).

세션 최종 (2026-07-26)

완료: P0 ①②③(③설계)·RCE 2건·P1 ④⑤⑥⑦·기능버그3건. 대기: P0-③구현(결정선행)·P2 ⑧⑩(설계)·⑨(보류)·anchor손상 복구·오프사이트.

⑧ 대용량 IO — 되돌림(revert) + VM코어 한계 규명 (2026-07-28~29)

★결론: ⑧(대용량 본문) 목표는 현 VM 코어로 불가. 여러 에이전트 시도+메인 심층검증 결과:

벽1: VM 문자열 STR_MAX_LEN 65535 — merge/store가 본문을 문자열로 파싱(JSON필드/LWW). 버퍼로 읽어도 파싱 위해 버퍼문자열()로 되돌리면 재봉착.
벽2: 다중 TCP읽기 필요한 큰 본문의 read-loop 누적이 불안정(빈카운터 재시도로도 미해결).
벽3: merge 항목수집 배열 ~4095 캡 초과 시 VM 프로세스 크래시(DoS 소지).
★테스트 아티팩트 교훈: 직접 localhost curl --data-binary(헤더/본문 2-write)는 실패하나 실클라이언트 경로=게이트웨이 경유는 소용량 정상. 직접 localhost는 실사용 경로 아님 → 검증은 반드시 게이트웨이(또는 raw 단일세그먼트)로.
조치: pre-⑧ 백업(.bak-대용량IO=auth+RCE+기능버그 포함)으로 복원·STRICT컴파일·cloud 단독 재기동(pid 갱신)·게이트웨이 소용량 15/15 200·인증/RCE 회귀0. ⑧본은 서비스서버.한선.ORIG-⑧회귀-2026-07-28로 보존.
진짜 해법 후보(별도 VM코어 작업): (a) crownyc.c STR_MAX_LEN 상향+버퍼-네이티브 JSON 파싱(30+서비스 공유라 고위험), (b) ★대용량은 blob 경로 이용(이미 64MB 동작) — merge/store엔 소형 메타만. ⑩ 오피스도 문서를 blob로 저장하면 이 벽 회피 가능.
pre-⑧ 상태: 실클라이언트(게이트웨이) 소용량 동기화 정상(07-07 이래 운영 상태 그대로). 대용량 merge/store는 원래부터 미지원.

⑩ 오피스 클라우드 미러 완료 (2026-07-29 — 사용자 결정=선택적 동기 추가)

crowny-ai:9852 /api/office/save에 best-effort 미러 배선: 로컬(data/office) 정본 유지 + 9611에 바이트=blob(64MB)·메타=merge(office-docindex 소형) 추가. 실패무해(로컬 저장 항상 성공), owner=office_<username> 변환. 신규 /api/office/cloud-list·cloud-get. 한선씨 동반 오피스클라우드미러.한선. ★검증(메인, 실경로): 500KB 문서 게이트웨이 다운로드 512000B·sha256 일치 — blob 우회로 대용량 실동작 확증(⑧이 merge로 못한 걸 blob로 달성). 로컬 회귀·409·실패무해 PASS. cloud/ai health 200. 잔여: cloud tombstone(delete 전파)·blob GC·대량 docindex 스트레스.

★세션 최종 종합 (2026-07-29)

완료: P0①②③·RCE 2건·P1④⑤⑥⑦·기능버그3건·anchor·⑩(오피스 blob미러). 방향전환: ⑧(대용량=blob우회, VM코어 미개봉). 보류: ⑨(과금=사업결정). 잔여 후속: cloud tombstone·blob GC·anchor 복구·오프사이트 백업.

← 이전크라우니캔버스 컬렉션(DB) 엔진 — F4 구현2026-07-24-크라우니캔버스-컬렉션엔진 다음 →crowny-butler 한선씨 일관화 (18모듈)2026-07-25-butler-한선씨-일관화