Dateiablage im Image anlegen, sonst schlaegt jeder Upload fehl
Prüfung / Lint, Typen, Tests (push) Canceled after 0s
Prüfung / Images bauen (pdf) (push) Canceled after 0s
Prüfung / Images bauen (web) (push) Canceled after 0s
Prüfung / Images bauen (worker) (push) Canceled after 0s
Images / bauen (pdf, docker/pdf.Dockerfile) (push) Canceled after 0s
Images / bauen (web, docker/web.Dockerfile) (push) Canceled after 0s
Images / bauen (worker, docker/worker.Dockerfile) (push) Canceled after 0s
Prüfung / Lint, Typen, Tests (push) Canceled after 0s
Prüfung / Images bauen (pdf) (push) Canceled after 0s
Prüfung / Images bauen (web) (push) Canceled after 0s
Prüfung / Images bauen (worker) (push) Canceled after 0s
Images / bauen (pdf, docker/pdf.Dockerfile) (push) Canceled after 0s
Images / bauen (web, docker/web.Dockerfile) (push) Canceled after 0s
Images / bauen (worker, docker/worker.Dockerfile) (push) Canceled after 0s
Das Volume `files` wird auf /data/files gelegt. Diesen Pfad gab es im Image nicht, also legte Docker ihn beim Einhaengen selbst an - als root mit 755. Der Dienst laeuft aber als afis (1001) und bekam beim ersten Schreibversuch EACCES. Betroffen war jeder Upload: Anhaenge, Lichtbilder, und auch die fertigen PDF-Abzuege, die in derselben Ablage landen. Nachgemessen statt vermutet: ein leeres Volume uebernimmt Verzeichnis und Eigentuemer aus dem Image, ein bereits befuelltes behaelt seine alten Rechte. Da bisher nie ein Upload durchkam, ist die Ablage leer - ein Neubau genuegt, das Volume muss nicht weg. Dazu die Ablage in die Statusanzeige. Sie war der zweite stille Ausfall dieser Art nach clamd: ein Zustand, den man nur durch Ausprobieren erfaehrt, gehoert dorthin, wo man ihn sieht. Geprueft wird das Schreibrecht, nicht durch eine Probedatei - ein Healthcheck, der im Sekundentakt schreibt und aufraeumt, waere selbst ein Risiko. Die Pruefung dazu stellt den echten Fall nach, ein leeres gesperrtes Verzeichnis. Mein erster Versuch sperrte nur das Elternverzeichnis, waehrend quarantine/ und store/ darin schon standen und beschreibbar blieben - der Dienst haette weitergearbeitet, und die Anzeige haette zu Recht nichts gemeldet.
This commit is contained in:
@@ -82,6 +82,23 @@ COPY --from=build --chown=afis:afis /repo/web/public ./web/public
|
||||
# Migrations-CLI samt Schema, Migrationsordner und Engine.
|
||||
COPY --from=build --chown=afis:afis /migrator ./migrator
|
||||
|
||||
# Die Dateiablage **muss im Image liegen**, sonst kann niemand hochladen.
|
||||
#
|
||||
# `files` ist ein benanntes Volume und wird auf /data/files gelegt. Existiert
|
||||
# dieser Pfad im Image nicht, legt Docker ihn beim Einhaengen selbst an - als
|
||||
# root mit 755. Der Dienst laeuft aber als afis (1001) und bekommt beim ersten
|
||||
# Schreibversuch EACCES: jeder Upload scheiterte mit einer nichtssagenden
|
||||
# Meldung, vom Lichtbild bis zum Anhang.
|
||||
#
|
||||
# Liegt das Verzeichnis dagegen im Image und ist leer, uebernimmt Docker es
|
||||
# samt Eigentuemer in ein leeres Volume. Nachgemessen: ein bereits befuelltes
|
||||
# Volume behaelt seine alten Rechte, ein leeres nicht.
|
||||
#
|
||||
# quarantine/ und store/ gleich mit anlegen - dieselben zwei Verzeichnisse, die
|
||||
# lib/files/paths.ts erwartet.
|
||||
RUN mkdir -p /data/files/quarantine /data/files/store && \
|
||||
chown -R afis:afis /data
|
||||
|
||||
USER afis
|
||||
EXPOSE 3000
|
||||
|
||||
|
||||
Reference in New Issue
Block a user