feat: refuse to start as root

The image runs as its own unprivileged user, and everything in run.sh now assumes it: keys.dat is worked on by its owner, no privilege is dropped anywhere, and what confines the container is whatever the caller passed. Started as root by a `user:` override, none of that holds and the container looks identical from outside -- a silent loss of every property this image was changed to have. Four lines at the top of run.sh, and the reason is then the first line of `docker logs`. It is the same bargain as the build-time checks: a wrong posture should fail loudly rather than pass for a right one.
2026-09-09 13:45:09 +00:00
parent 68eb019e59
commit 29a0957cb7
3 changed files with 18 additions and 2 deletions
@@ -165,7 +165,9 @@ docker run -d \
  которые заводит сам демон — `knownnodes.dat` и `messages.dat`, — он заводит в
  своём домашнем каталоге. Ничего не понижается на старте, потому что повышенных
  прав изначально нет. Ни на одном файле образа нет бита setuid или setgid, так
-  что захваченному демону не по чему подниматься.
+  что захваченному демону не по чему подниматься. Вызывающая сторона, вернувшая
+  пользователя в root, получит отказ первой строкой журнала, а не контейнер,
+  который выглядит так же и не ограничивает ничего.

  Плата за это — bind-монтирование. Каталог `/home/bitmessage`, приехавший с
  хоста, должен принадлежать uid 2000: сменить владельца на входе контейнер