Repository navigation
fix: restrict host-level schedule creation to owners and admins - #22
Merged
Merged
Conversation
Что: - schedule.create для расписаний без сервиса (типы dokploy-server и server) теперь вызывает assertHostScheduleAccess, как уже делают update, delete, runManually и list. - Тесты: участник не может создать расписание dokploy-server или server (FORBIDDEN, в базу ничего не пишется); админ может создать dokploy-server. Зачем: - Роль member по умолчанию имеет schedule.create. Без этой проверки любой участник мог создать расписание dokploy-server, и его скрипт запускался от root в контейнере Dokploy с доступом к Docker-сокету, /etc/dokploy и переменным панели, то есть ко всем секретам. Для типа server скрипт запускался по SSH на сервере. - После восстановления запуска расписаний dokploy-server (PR #9) это стало реально исполнимым. Риски: - Участники без роли owner/admin больше не могут создавать расписания уровня сервера. Расписания приложений и compose не меняются. Проверки: - Команды и результаты: CI=true bunx vitest run --config __test__/vitest.config.ts __test__/schedule/schedule-router-boundary.test.ts - на старом коде 2 новых теста падают (участник создаёт расписание), после правки проходят; все тесты __test__/schedule: 32 прошли. Полный прогон: 2096 прошли, 1 пропущен, 8 упали только в *.real.test.ts (нет сокета Docker Desktop). bun run typecheck - 4/4 без ошибок. bunx biome check для изменённых файлов - 0 ошибок. - Ограничения: на dev ещё не выкатывалось. What: - schedule.create for schedules without a service (dokploy-server and server types) now calls assertHostScheduleAccess, as update, delete, runManually and list already do. - Tests: a member cannot create a dokploy-server or server schedule (FORBIDDEN, nothing is written); an admin can create a dokploy-server schedule. Why: - The member role has schedule.create by default. Without this check any member could create a dokploy-server schedule, and its script ran as root in the Dokploy container with access to the Docker socket, /etc/dokploy and the panel's environment, that is, to every secret. For the server type the script ran over SSH on the server. - Once dokploy-server schedule runs were restored (PR #9), this became exploitable. Risks: - Members without the owner/admin role can no longer create server-level schedules. Application and compose schedules are unchanged. Checks: - Commands and results: CI=true bunx vitest run --config __test__/vitest.config.ts __test__/schedule/schedule-router-boundary.test.ts - on the old code the 2 new tests fail (a member creates the schedule), after the fix they pass; all tests in __test__/schedule: 32 passed. Full run: 2096 passed, 1 skipped, 8 failed only in *.real.test.ts (no Docker Desktop socket). bun run typecheck - 4/4 clean. bunx biome check on the changed files - 0 errors. - Limitations: not deployed to dev yet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this PR about?
schedule.createdid not callassertHostScheduleAccessfor schedules without a service (dokploy-serverandservertypes), whileupdate,delete,runManuallyandlistalready do. The basememberrole hasschedule.create, so any member could create adokploy-serverschedule. Its script runs as root inside the Dokploy container, which has the Docker socket,/etc/dokployand the panel's environment, so every secret on the host is reachable. Aserverschedule ran its script over SSH on the server.#9 restored
dokploy-serverschedule runs, which made this exploitable again.The fix adds the same
assertHostScheduleAccess(ctx, scheduleType, input.serverId)call tocreate: owners and admins only, and nodokploy-serverschedules in cloud. Application and compose schedules are unchanged.Checks
__test__/schedule/schedule-router-boundary.test.ts: a member creating adokploy-serverorserverschedule getsFORBIDDENand nothing is written (both fail on the old code); an admin can still create adokploy-serverschedule.__test__/schedule: 32 tests pass.vitest run: 2096 pass, 1 skipped; the 8 failures are only in*.real.test.ts(no local Docker socket).bun run typecheck: 4/4 packages pass. Biome: no errors in the changed files.Rollout notes
Members can no longer create server-level schedules; owners and admins can. Existing schedules are not touched.
🤖 Generated with Claude Code