16 권한 — 건네받는 힘

16.1 권한의 종류#

권한은 input <이름> cap <종류> . 로 받는다. 종류가 그 권한으로 할 수 있는 일을 정한다.

종류를 나누는 까닭은 최소 권한이다. 권한이 하나뿐이면 파일을 읽으려고 받은 자격이 연결도 열 수 있게 되고, 그러면 op 의 머리가 “이 op 이 무엇을 할 수 있는가” 를 더는 말해 주지 못한다.

16.2 권한은 사슬을 타고 내려간다#

권한을 다시 넘길 때 특별한 표기는 없다. 받은 이름을 다른 인자처럼 적는다.

module chain .
rem run: main

proc say input k cap io . input msg slice u8 . output u64 . effects io .
do
  return write_out k 1 msg .
end

proc say_twice input k cap io . input msg slice u8 . output u64 . effects io .
do
  let a u64 be say k msg .
  let b u64 be say k msg .
  return add a b .
end

proc main input k cap io . output u8 . effects io .
do
  let n u64 be say_twice k "hi\n" .
  guard eq n 6 . else return 1 .
  return 0 .
end

$ lowentc --run main chain.low
hi
hi
main() = 0

사슬은 이렇게 생긴다 — 바깥 → main 의 k → say_twice 의 k → say 의 k → write_out. 효과와 함께 그리면 두 화살표가 반대로 흐른다.

                  권한 (허락)                      효과 (한 일)
                  위에서 아래로 건넨다              아래에서 위로 번진다
  바깥(운영체제)
      │ cap io
      ▼
  main       k ─────────────┐                  ▲ effects io
      │                     │                  │
      ▼                     ▼                  │
  say_twice  k ─────────────┐                  ▲ effects io
      │                     │                  │
      ▼                     ▼                  │
  say        k ─────▶ write_out k 1 msg        ▲ effects io   ← 여기서 io 가 생긴다

권한은 위에서 건네받아야 쓸 수 있고, 효과는 아래에서 생겨 부르는 쪽 머리마다 적힌다. 그래서 어느 op 의 머리만 보면 «이 op 이 무엇을 할 수 있고(효과), 누가 그것을 허락했는지(권한)» 가 다 보인다. 권한을 받지 않은 op 은 say 를 부를 수 없다. 넘길 것이 없기 때문이다. 그래서 “이 프로그램이 파일을 건드릴 수 있는가” 를 시작점만 보고 답할 수 있다. 깊은 곳의 어떤 op 이 몰래 파일을 여는 일은 있을 수 없다. 권한을 받지 않았다면 열 수 없고, 받았다면 그 사슬이 시작점까지 이어져 보인다.

16.3 효과와 권한은 짝이다#

효과 줄은 op 이 무엇을 하는지, 권한 입력은 누가 허락했는지를 적는다. 같은 일을 두 쪽에서 적고 서로를 검사한다.

module pairs .
rem run: main

proc main input out cap io . input al cap allocator . output u8 . effects io alloc .
do
  let g option mut slice u8 be alloc_bytes al capacity 16 .
  guard is_some g . else return 1 .
  let n u64 be write_out out 1 "hi\n" .
  return 0 .
end

$ lowentc --run main pairs.low
hi
main() = 0

main 이 두 권한을 받는다. cap io 가 effects io 를, cap allocator 가 effects alloc 을 허락한다. alloc_bytes al capacity 16 은 할당기에서 16 바이트를 청하고, 얻지 못할 수 있으므로 option 을 준다.

짝이 어긋나는 모양은 셋이다. 효과를 적었는데 허락하는 권한이 없으면 거절된다.

module nocap .
rem expect: E-EFFECT-NO-CAP

proc main output u8 . effects io .
do
  let n u64 be write_out 1 "hello\n" .
  return narrow u8 n .
end

$ lowentc --check nocap.low
nocap.low:4:0 E-EFFECT-NO-CAP: this op declares the `io` effect but receives NO capability that authorizes it. `io` is a cap-effect (RFC-0007 §6.7): I/O is a RIGHT you are HANDED, not an ambient power — `input fs cap file_system .` (or another `cap …` input). An effect you declare but hold no capability for is a claim the signature cannot back

할당도 같다. 메모리를 쓰겠다고 적고 그 자리를 어디서 받는지 적지 않았다.

module alloc_nocap .
rem expect: E-ALLOC-NOCAP

proc scratch output u8 . effects alloc .
do
  return 1 .
end

$ lowentc --check alloc_nocap.low
alloc_nocap.low:4:0 E-ALLOC-NOCAP: this op declares the `alloc` effect but receives NO allocation capability. There is no ambient heap in this language (RFC-0043 D1): to allocate you must be HANDED the right — `input a cap allocator .` or `input r region <name> . .` (a region IS an arena allocator, RFC-0043 D7). An allocation nobody granted is exactly the hidden dependency this model removes
alloc_nocap.low:5:1 W-EFFECT-OVER: this op DECLARES `alloc` but never PERFORMS it. A declared effect is a cost the caller must budget for (a pure caller cannot call an `io` op). Drop it, or — if a future version will perform it — say so (RFC-0007)

권한을 받아 두기만 하고 쓰는 자리에 건네지 않아도 거절된다. 권한을 요구하는 내장 op 은 그 권한을 첫 피연산자로 적는다.

module missing .
rem expect: E-CAP-MISSING

proc hello input out cap io . output u64 . effects io .
do
  return write_out 1 "hello\n" .
end

$ lowentc --check missing.low
missing.low:6:0 E-CAP-MISSING: `write_out` writes to the process output and needs the `cap io` value the entry received as its FIRST operand — output is a RIGHT you are handed (RFC-0030 D2), never ambient. There is no hidden stdout

이름 없이 권한에 닿는 길은 없다. 숨은 표준출력이 없다는 뜻이다.

16.4 있음이 아니라 종류다#

권한 값을 하나 가지고 있다고 모든 문이 열리지는 않는다.

module kind .
rem expect: E-CAP-KIND

proc stamp input out cap io . output u64 . effects none .
do
  return time_now out .
end

$ lowentc --check kind.low
kind.low:6:0 E-CAP-KIND: this host leaf was handed a capability of the WRONG KIND. Authority is by KIND, not by mere presence: an unrelated right (io, net, …) does not authorize the clock, the filesystem, the socket or the OS entropy (RFC-0083 L3 · RFC-0077 §P1-2). Take the right this leaf names — the FFI boundary has always been checked this way (E-FFI-CAPKIND); the host leaves used to be refused only at lowering, where a WRONG RIGHT was reported as an UNSUPPORTED FEATURE

time_now 는 시계를 읽는 원시 연산이다. cap io 를 건넸으므로 종류가 틀렸다고 거절된다. 권한은 무엇인가로 인가된다.

권한의 이름은 저자가 지을 수 있다. input logger cap audit . 처럼 자기 권한을 만들어 매개변수로 받으면, 그 권한을 받은 op 만 부를 수 있는 op 을 만들 수 있다. 처리기가 뜻을 정해 둔 것은 위 표의 종류들이고, 그 종류의 일을 하려면 그 종류를 건네야 한다.

16.5 시작점이 받는 것#

프로그램이 시작하는 op 은 권한만 받는다. 자료를 받지 않는다. 건네줄 사람이 없기 때문이다.

module entry .
rem expect: E-ENTRY-PARAMS

proc main input out cap io . input n u64 . output u8 . effects io .
do
  return narrow u8 n .
end

$ lowentc --check entry.low
entry.low:4:0 E-ENTRY-PARAMS: the entry point takes CAPABILITY inputs only (`input a cap args .`). A data parameter here would be a magic argv — RFC-0030 D2 rejects that: arguments are a RIGHT the runtime hands you, queried via `count`/`arg` on the cap
entry.low:5:1 W-EFFECT-OVER: this op DECLARES `io` but never PERFORMS it. A declared effect is a cost the caller must budget for (a pure caller cannot call an `io` op). Drop it, or — if a future version will perform it — say so (RFC-0007)

C 의 argv 같은 마법의 인자는 없다. 프로그램 인자도 cap args 로 받는 권한이다. 시작점이 받을 수 있는 권한은 닫힌 목록이다 — args·env·io·allocator·heap·file_system·net·tty·clock·random·atomic. 그 밖의 권한(mmio·machine·c)은 실행하는 쪽이 건넬 수 있는 것이 아니라서 시작점이 요구하면 E-ENTRY-CAP 으로 거절된다. 그런 권한은 그것을 줄 자격이 있는 자리에서 만들어져 인자로 흘러야 한다(29·30장).

환경 변수와 운영체제의 난수도 권한으로 받는다.

module envrandom .
rem run: main

use random .

rem 환경 변수는 cap env, 운영체제의 엔트로피는 cap random — 둘 다 받아야 닿는다
proc main input e cap env . input r cap random . input al cap allocator . output u8 . effects alloc .
do
  let g option mut slice u8 . . be alloc_bytes al capacity 8 .
  guard is_some g . else return 250 .
  var buf mut slice u8 . be some_value g .
  rem 여덟 바이트를 운영체제의 난수로 채운다 — 값은 매번 다르므로 돌려주지 않는다
  let n u64 be random.bytes r buf .
  rem 환경 변수가 없으면 none — 값이 아니라 없음을 돌려준다
  let v option slice u8 be env_get e "LOWENT_MANUAL_DEMO" .
  guard is_some v . else return narrow u8 n .
  return 99 .
end

$ lowentc --run main envrandom.low
main() = 8

env_get e "…" 은 cap env 가, random.bytes r buf 는 cap random 이 있어야 부를 수 있다. 환경 변수는 프로그램 밖에서 조용히 동작을 바꾸는 통로이고, 난수는 같은 입력에도 답을 바꾸는 통로다. 둘 다 머리에 보여야 “이 프로그램의 답은 입력만으로 정해지는가” 를 머리만 보고 판단할 수 있다. 변수가 없으면 env_get 은 none 이고, 예제는 채운 바이트 수 8 을 돌려준다. 시험에서 되풀이할 수 있는 난수가 필요하면 권한이 필요 없는 rng_next (씨앗에서 다음 수)를 쓴다.

16.6 흔한 실수#

module mistake_fncap .
rem expect: E-EFFECT-CALC

rem ✘ 권한을 받았다고 `fn` 이 출력할 수 있게 되지는 않는다
fn say input out cap io . output u64 .
do
  return write_out out 1 "hi\n" .
end

$ lowentc --check mistake_fncap.low
mistake_fncap.low:6:1 E-EFFECT-CALC: this fn is declared pure but performs `io` — make it a `proc` with `effects …`, or remove the effect

module mistake_caplocal .
rem expect: E-CAP-LOCAL

proc say input out cap io . output u64 . effects io .
do
  rem ✘ 권한을 지역 이름에 옮겨 담았다 --- 받은 이름을 그대로 건넨다
  let k cap io be out .
  return write_out k 1 "hi\n" .
end

$ lowentc --check mistake_caplocal.low
mistake_caplocal.low:8:0 E-CAP-LOCAL: `k` is a LOCAL that a `cap io` was copied into. A capability is not a value you carry in a local name: only a parameter of this op names a right it was handed, so hand the parameter itself to the leaf (RFC-0030 D2)

module mistake_fscapout .
rem expect: E-CAP-KIND

rem ✘ 파일 권한으로 표준출력에 쓰려 한다
proc main input fs cap file_system . output u8 . effects io .
do
  let n u64 be write_out fs 1 "hi\n" .
  return 0 .
end

$ lowentc --check mistake_fscapout.low
mistake_fscapout.low:7:0 E-CAP-KIND: this leaf needs a `cap io`, and `fs` is a `cap file_system`. One capability never stands in for another: each names a different right, and holding one says nothing about the other (RFC-0011)

module mistake_capforge .
rem expect: E-CAP-FORGE

proc say input k cap io . output u64 . effects io .
do
  return write_out k 1 "hi\n" .
end

rem ✘ 권한을 하나도 받지 않았는데, 권한 자리에 수 0 을 넘겨 출력한다
proc start output u8 .
do
  let n u64 be say 0 .
  return 0 .
end

$ lowentc --check mistake_capforge.low
mistake_capforge.low:12:0 E-CAP-FORGE: a LITERAL was passed where a capability is taken. A capability is handed over, never conjured: it can only be a name you were given (an `input … cap …`) or an actor's capability field (RFC-0030 D2). Passing a number here would let an op that received NO right reach the outside, and then the entry point no longer tells what the program can touch. The placeholder `0` means something only at the tool's door (`--run`)

module capjustincase .
rem expect: W-EFFECT-OVER

rem 나중에 쓸지도 몰라 권한과 효과를 미리 적어 두었다
proc area input out cap io . input w u64 . input h u64 . output u64 . effects io .
  requires le w 1000 .
  requires le h 1000 .
do
  return mul w h .
end

$ lowentc --check capjustincase.low
capjustincase.low:8:1 W-EFFECT-OVER: this op DECLARES `io` but never PERFORMS it. A declared effect is a cost the caller must budget for (a pure caller cannot call an `io` op). Drop it, or — if a future version will perform it — say so (RFC-0007)

16.7 이 장의 문법 한눈에#