b85563b1b8
All checks were successful
CI / secret-scan (pull_request) Successful in 8s
CI / static-tests (pull_request) Successful in 34s
CI / auto-merge (pull_request) Successful in 5s
CI / php-lint (pull_request) Successful in 22s
CI / secret-scan (push) Successful in 9s
CI / php-lint (push) Successful in 24s
CI / static-tests (push) Successful in 37s
CI / auto-merge (push) Has been skipped
L'image mariadb cree MARIADB_USER avec GRANT ALL PRIVILEGES sur la base, ce qui donnait au code back-office expose un acces DDL/DROP/GRANT dont il n'a aucun usage (les migrations tournent en root). La doc (compose, backup-db.sh) decrivait pourtant un moindre privilege jamais applique. - db/init/10-scope-app-user.sh : script d'init MariaDB (volume vierge) qui REVOKE ALL puis GRANT le set restreint SELECT/INSERT/UPDATE/DELETE + SHOW VIEW/TRIGGER/ LOCK TABLES (DML + besoins mysqldump), parametre sur MARIADB_USER/DATABASE. - docker-compose.yml : montage de db/init en /docker-entrypoint-initdb.d (ro). - backup-db.sh : commentaire aligne sur le set reel (mysqldump --single-transaction n'exige que SELECT + SHOW VIEW/TRIGGER). Verifie : sur volume vierge le user ressort scope (plus de ALL PRIVILEGES) ; sur la base dev (scopee manuellement, hors volume vierge) /api/health=200 (SELECT) et les 13 tests d'integration passent (DML create/update/delete en tant que wakdo). |
||
|---|---|---|
| .. | ||
| apache | ||
| cron | ||
| php-fpm | ||