Нормальна ли практика деплоя от root и кто отвечает за разграничение прав на VPS?

Question

[Arn984575]

Есть production-сервер на Ubuntu 16.

Я предлагаю стандартную модель:
создать отдельного пользователя deploy, настроить владельца проекта как deploy:www-data, разграничить права и выполнять деплой через rsync на край через git без использования root.

Системный администратор отказывается менять права и создавать отдельного пользователя, настаивает на работе от root. В случае ошибки ответственность, по его словам, не его. Руководство полностью доверяет администратору.
Дополнительный нюанс: runtime-директории (storage и др.) находятся внутри проекта и не вынесены отдельно.

При деплое через rsync --delete, если по ошибке не подхватится переменная или будет указан неверный путь, теоретически можно затереть runtime-данные. Если эти директории принадлежат www-data:www-data, пользователь deploy просто не сможет их переписать — что служит дополнительной защитой. При работе от root такой защиты нет.

Также понятно, что вероятность ошибки невысока, но риск при работе от root существенно выше: при неверном пути можно повредить данные проекта или затронуть системные каталоги.

Я сам могу все настроить но это не моя зона ответственности.

Вопросы:

Является ли деплой от root нормальной практикой в production?

Входит ли в обязанности системного администратора настройка пользователей, групп, прав доступа и SSH-ключей (а не только сети и firewall)?

Лучше сразу уйти с такой работы?

Comments

[Everything_is_bad]

Ubuntu 16.

уже ненормальная практика

настаивает на работе от root.

чем обосновывает?

Входит ли в обязанности системного администратора настройка пользователей, групп, прав доступа и SSH-ключей

обычно входит. В идеале обязанности должны быть закреплены документально.

[Arn984575]

Everything_is_bad,
1. Согласен Ubuntu 16 бред. Когда я собрал php образ php 7 в докере через docker compose со всеми зависимостями и нормальными конфигами MySQL и php. Переезд сломает crm
2. Работает давно уровень доверия высокий. Говрит настройка прав сломает crm.
3. Обязанности писала девочка в 2015 году. Обслуживание серверов и ремонт вэб приложений :))))

[SunTechnik]

Arn984575,
Скорее всего - админ в возрасте. Основной принцип работы: работает - не трож.

Но так как планов миграции с текущей версии Ubuntu нет - на безопасность положили болт ( обновлений по безопасности не будет с апреля 2026 года, да и сейчас, если посмотреть CVE, многое не закрывается.

Практика работы напрямую от root - порочна. (Вообще что разрешен прямой вход root).

Выглядит - что на этом месте работы сейчас хорошему не научат, но:
- Если зарплата в рынке
- По рукам не бьют и есть желание себя проявить - можно пытаться разгрести эти авгиевы конюшни..

Ну и любая инициатива - наказуема :)

[pfg21]

написать отказ от ответственности в случае работы системы от root. описать возможные последствия. подписать у админа и у директора/ответственного...
как говорится документально снять с себя ответсвеность...
мож прокатит.

[Adamos]

Рут в линуксе существует для администрирования.
Работа под рутом "попахивает" вне зависимости от того, что это за работа.
Веб-сервер под рутом - это даже не бэкдор, это бэк-парадный подъезд.

настройка прав сломает crm

Но вы-то умеете в докер? Запускаете у себя сервер разработки с нормальными правами, поднимаете на нем эту CRM - и проверяете это утверждение. Для разгребания конюшни и разборок с тем говнокодом, который там дерьмоточит в логи, это все равно понадобится.

Answer 1

[Refguser]

Твои вопросы показывают отсутствие опыта и необходимых знаний. Но не переживай, это наживное :)
Для начала - все рабочие процессы сотрудников должны быть регламентированы должностной инструкцией. Тогда вопрос кто что должен и за что отвечает сразу отпадает.
Если на предприятии нет ДО и всё держится на честном слове (ака "доверии") - это рано или поздно приводит к проблемам.

Потом - чтобы попытаться добиться от руководства того, что по твоему мнению важно (и указать на недостатки существующей системы) бывает недостаточно просто рассказать устно. Особенно когда есть противодействующая сторона. Тогда составляется служебная записка где отражаются недостатки (с упором на финансовые и другие потери и риски) и предлагается решение, с обязательным хорошо и понятно прописанным профитом от внедрения. СЗ вначале подаётся непосредственному руководству. Если результат нет - постепенно выше.

Answer 2

[Drno]

Да делайте как удобно. у меня на одном сервере так, на другом эдак, на третьм заказчик потребовал вообще по "сяк" сделать...

каждый работает как считает нужным.

про зоны ответственности - кто за VPS отвечает, тот и решает как делать.

ну и не забываем про бэкапы, эт к вопросу затирания.

насчет rsync - я пока не встречал такого, чтоб он не подхватил переменные...

насчёт деплоя - делай в новую папку... чтоб пред оставалась. тогда и проблемы нет если ошибка в деплое

Comments

[Everything_is_bad]

ага, очень удобно кому-то будет, деплой от root, поди и запуска проекта от root, уязвимость в проекте - сразу root доступ.

[Arn984575]

Похоже, придётся либо смириться с текущим порядком вещей, либо принимать более радикальные решения и уходить. Но по мне бардат такой не норм. 97% диск заполнен. 100gb warning и noise от php на почте root. При этом на меня еще накричали чего я сам по серверу лажу.)) База крутится на одной впс с приложением делят iops с приложением и х2 фронтами. Конфиг для бд на 512мб стандартный для 5.7. MySQL. Когда индексов только на 1.8гб. Причем до меня чел делал миграции и там куча дублей индексов. С 2018 года как то работает. Фронт crm на php. Фронт lk на Vue 2 исходников нету багов милион. :))

[Drno]

Everything_is_bad, у меня именно так и сделано на серверах. правда в рут никто кроме меня не лазает

[Drno]

Arn984575, ну уходить или нет решать тебе. а так - ну вот сформулируй тебе этот краткий анализ по номарльному текстом, и отдать главнюку с обоснованиями.
вот и всё...

дальше пусть решает сам

[Михаил Ливач]

Arn984575, ключевая фраза "как-то работает". Куча проектов так и живут. Для аналогии: куча людей ездит не пристёгиваясь - и ничего. Даже заглушки в гнездо ремня безопасности продаются.
Вопрос в том, кто будет отвечать, если случится авария. Если не вы - никкаких проблем, делайте как говорят. Только предварительно обеспечьте себе документ (бумажный), подписанный либо тем самым ответственным лицом, либо руководством, где прописано, кто ответственный.
Если ответственный - вы, то из наличия ответственности естественно вытекает право решать, как и что должно быть устроено.

Answer 3

[AntHTML]

А там только СА? ИБшников нету или в одном лице?
Попробуйте, то что описали довести до руководства, в том числе и письменно.
Так-то по хорошему, на проде рута вообще быть не должно, точнее на неко должен стоять жесткий хэш пароль с обязательным оповещением о входе. Т.к. вход под рутом на прод это жесткий инцидент в ИБ - разрабов можно отрулить правами как вы и описали.

Comments

[Arn984575]

Подготовил отчёт по рискам, описал проблемные зоны, предложил решения.

По сути, единственное, чего удалось добиться — это минимальный тюнинг конфигурации вчера.

Ситуация абсурдная: объём индексов 1.8 ГБ, а innodb_buffer_pool_size был 256 МБ. Это базовый уровень настройки, который должен был быть приведён в порядок давно.

Ощущение, что к моим аргументам доверия нет. Администратор — руководитель отдела в государственной структуре, но при этом моя тестовая песочница работает в разы быстрее продакшена.

После этого становится понятно, почему государственные сервисы годами функционируют нестабильно.

Так то я в шоке как бывает.

[Михаил Ливач]

Arn984575, нужно общаться с тем, кому подчинён этот администратор. Если он - ваш непосредственный руководитель, то имеет смысл увольняться или переходить в другое подразделение. Маячить перед дураком с табличкой "ты - дурак", когда у дурака есть власть над вами, крайне неразумно.

Answer 4

[Кот Абсолютный]

Является ли деплой от root нормальной практикой в production?

Столкнулся я недавно с похожей ситуацией. Пришлось целый скрипт написать по деплою.

Установка программ - это исключительно прерогатива админа. Разраб на боевом сервере должен иметь права (если он там вообще есть) обычного юзера.

За работу сервера отвечает админ

То есть, если сервер ляжет (тем более 16 бубунта, вышедшая 10 лет назад (десять, Карл!)) - кто будет отвечать? Правильно, админ. Поэтому и не должно быть никаких деплоев не от рута.

Здесь надо сказать, что практика деплоя самим разрабом (даже в ограниченных условиях) - это вообще неправильно. Разраб должен отладить проект у себя, потом подготовить дистриб и доки, по которым админ установит сам.

Даже допуск разраба к деплою - это уже серьезное послабление. У меня сделано как - есть некий скрипт, который запускается через sudo. Этот скрипт сам заберет последнюю версию приложения с гита, сам распакует, сам расставит все по местам. По идее это все нужно было в portage оформить, но времени нет, свое налабать проще...

Если есть замечания по безопасности - стоит сначала написать об этом непосредственно ответственному, то есть админу. Если он ничего не говорит или тупо без обьяснений отказывает - идти к руководству отдела. Не нужно влезать в конфликт непосредственно - вполне может так случиться, что "там" договорятся, а Вас обьявят стрелочником :)

Не Ваша зона ответственности -- не отвечайте. Игры ы "теневого админа", "теневого директора" (а вот я бы на месте ... сделал... ) ни к чему не приводят.

Админ отвечает за работу сервера. Полностью. Если что-то ложится, то винова в первую очередь он, именно потому что только у него права что-то менять на сервере.

Answer 5

[ky0]

Какой ещё деплой через rsync и 16-ая Убунта в 2026 году?

Собираете образ docker-контейнера и запускаете. От кого он там будет запускаться - не ваша проблема.