Лог один, поэтому вопрос почти не возникает. Hermes сам никуда не пишет: он говорит по stdio через ACP, всё выходит на stdout гейтвея. Один поток, один порядок времени.
Настоящие строки, id укоротил:
[agent:nested] session=agent:hermes:acp:edf5ff53-… run=21b8ea1c-… channel=webchat …текст…
[agents/agent-command] [agent] run announce:v1:agent:hermes:acp:f75583cb-… ended with stopReason=stop
[telegram] outbound send ok chatId=… messageId=415
Кто это сделал — зашито в ключ сессии agent:hermes:acp:<uuid>. Префикс [agent:nested] отделяет исполнителя от оркестратора, run=<uuid> не даёт слипнуться двум прогонам. Настраивать ничего не пришлось.
Плохо вот что. Ротации нет: docker inspect показывает {"Type":"json-file","Config":{}}, лимитов ноль, файл растёт до конца диска. Диск на этой машине один раз уже уходил в 100% и уронил бэкапы. Хранилища и поиска тоже нет, это docker compose logs | grep, и лежит всё на той же машине, что и логируемое.
Ещё: в логах сессии разделены, на диске не всегда — всё без явного профиля песочницы пишет в один /workspace. Кто из двух перезаписал файл, уже не спросишь.
И про «где сломалось». Пост-фактум по логу видно до конкретного run и stopReason. В реальном времени как повезёт: делегирование — не переключатель, а поведение модели, Kimi иногда игнорирует streamTo. Результат приходит всегда, промежуточные шаги когда как.
$ id
uid=1001(...) groups=1001,27(sudo),988(docker)
$ id hermes
uid=1002(hermes) groups=1002(hermes),988(docker)
$ ls -ld ~/.openclaw /home/hermes
drwx------ ubuntu ubuntu /home/<я>/.openclaw
drwxr-x--- hermes hermes /home/hermes
Данные OpenClaw принадлежат uid 1000 — системному ubuntu, который был на машине до меня. Hermes на 1002, без sudo. Я на 1001 и ~/.openclaw в собственном домашнем каталоге прочитать не могу.
В сторону Hermes закрыто плотно. У контейнера OpenClaw один ключ, read-only, и в authorized_keys к нему привязано command="…hermes acp",no-pty,no-port-forwarding,no-agent-forwarding,no-user-rc. Скомпрометированный оркестратор получит stdio с процессом и всё. docker.sock из контейнера выкинут.
В обратную сторону вы правы. По правам hermes у OpenClaw не читает ничего, но он в группе docker — иначе не работает его песочница. Группа docker равна root на хосте: docker run -v /:/mnt, и все эти 700 становятся украшением.
Смягчает то, что чужой код исполняет не хост-процесс Hermes, а его контейнер: CapDrop=[ALL], не privileged, сокет внутрь не проброшен. Чтобы дотянуться до группы docker, надо сначала сбежать из песочницы.
Решение осознанное, записано у меня в компромиссы. Закрывается rootless-докером или socket-proxy вместо членства в группе. Пока не сделано — и это первое, что придётся закрыть, когда в allowlist появится второй человек.
Лог один, поэтому вопрос почти не возникает. Hermes сам никуда не пишет: он говорит по stdio через ACP, всё выходит на stdout гейтвея. Один поток, один порядок времени.
Настоящие строки, id укоротил:
Кто это сделал — зашито в ключ сессии
agent:hermes:acp:<uuid>. Префикс[agent:nested]отделяет исполнителя от оркестратора,run=<uuid>не даёт слипнуться двум прогонам. Настраивать ничего не пришлось.Плохо вот что. Ротации нет:
docker inspectпоказывает{"Type":"json-file","Config":{}}, лимитов ноль, файл растёт до конца диска. Диск на этой машине один раз уже уходил в 100% и уронил бэкапы. Хранилища и поиска тоже нет, этоdocker compose logs | grep, и лежит всё на той же машине, что и логируемое.Ещё: в логах сессии разделены, на диске не всегда — всё без явного профиля песочницы пишет в один
/workspace. Кто из двух перезаписал файл, уже не спросишь.И про «где сломалось». Пост-фактум по логу видно до конкретного
runиstopReason. В реальном времени как повезёт: делегирование — не переключатель, а поведение модели, Kimi иногда игнорируетstreamTo. Результат приходит всегда, промежуточные шаги когда как.Юзер не один, их три:
Данные OpenClaw принадлежат uid 1000 — системному
ubuntu, который был на машине до меня. Hermes на 1002, без sudo. Я на 1001 и~/.openclawв собственном домашнем каталоге прочитать не могу.В сторону Hermes закрыто плотно. У контейнера OpenClaw один ключ, read-only, и в
authorized_keysк нему привязаноcommand="…hermes acp",no-pty,no-port-forwarding,no-agent-forwarding,no-user-rc. Скомпрометированный оркестратор получит stdio с процессом и всё.docker.sockиз контейнера выкинут.В обратную сторону вы правы. По правам hermes у OpenClaw не читает ничего, но он в группе
docker— иначе не работает его песочница. Группа docker равна root на хосте:docker run -v /:/mnt, и все эти 700 становятся украшением.Смягчает то, что чужой код исполняет не хост-процесс Hermes, а его контейнер:
CapDrop=[ALL], не privileged, сокет внутрь не проброшен. Чтобы дотянуться до группы docker, надо сначала сбежать из песочницы.Решение осознанное, записано у меня в компромиссы. Закрывается rootless-докером или socket-proxy вместо членства в группе. Пока не сделано — и это первое, что придётся закрыть, когда в allowlist появится второй человек.