Права доступа и владельцы файлов на игровом сервере

Игровой сервер работает от имени одного обычного пользователя и может читать, записывать или запускать только те файлы, которые этому пользователю разрешают права Linux. Почти каждое «Permission denied» на игровом сервере вызвано одной из трёх вещей: файл создан другим пользователем (обычно root, на машине, которой вы управляете сами), у скрипта или бинарника после загрузки пропал бит исполнения, или кто-то намеренно сделал файл доступным только для чтения и забыл об этом. В панели вопрос владельцев в основном решён за вас - всё в папке сервера принадлежит тому же пользователю, от имени которого работает сервер, - так что остаются режимы и второй, отдельный слой прав: кому из вашей команды панель разрешает трогать какие файлы.

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

Два слоя прав#

Их полезно разделять, потому что ломаются они по-разному.

1. Права файлов Linux определяют, что игровой процесс может сделать с файлом. Если они неверны, ломается игра: она не может сохраниться, загрузить плагин, запуститься.
2. Права панели определяют, что человек может сделать через файловый менеджер панели и SFTP. Если они неверны, заблокирован человек - или, что хуже, не заблокирован, когда должен быть.

Файл может быть прекрасно доступен игре и полностью скрыт от модератора или доступен модератору для правки и недоступен игре для чтения. Когда что-то запрещено, первый вопрос - какой слой сказал «нет»: ошибка в консоли игры - это первый слой, ошибка в файловом менеджере или SFTP-клиенте - обычно второй.

Как читать права Linux#

У каждого файла и папки есть владелец, группа и режим. ls -l показывает все три:

-rw-r--r-- 1 steam steam   1843 Oct  6 21:14 server.properties-rwxr-xr-x 1 steam steam    412 Oct  6 21:10 start.shdrwxr-xr-x 5 steam steam   4096 Oct  6 21:20 world-rw------- 1 root  root     96  Oct  6 20:55 token.txt

Первые десять символов - тип и режим. Первый символ - - для файла или d для каталога. Следующие девять - три группы по три: что может делать владелец, что могут делать члены группы и что могут делать все остальные. В каждой группе r - чтение, w - запись, x - исполнение.

Для каталогов буквы означают немного другое, и на этом люди спотыкаются:

В каталог без x нельзя войти, даже если каждый файл внутри доступен для чтения. Каталог без w не даёт удалить файл внутри, даже если сам файл доступен для записи. Играм, которые пишут сохранение, создавая новый файл и переименовывая его поверх старого, нужен w на каталоге, а не только на сохранении.

Режимы часто записывают тремя восьмеричными цифрами, по одной на группу, складывая 4 за чтение, 2 за запись и 1 за исполнение:

Новые файлы получают режим из umask создающего процесса, обычно 022, что даёт 644 для файлов и 755 для каталогов.

Владельцы: ловушка root#

На машине, которой вы управляете сами, - VDS, домашнем сервере - самая частая проблема с правами такая: сервер работает от непривилегированного пользователя (скажем, steam), а в папке полно файлов, созданных root. Происходит это так: вы устанавливаете игру от имени steam, а однажды вечером запускаете обновление или распаковываете мод от root через sudo. Эти новые файлы принадлежат root с режимом 644, и steam может их читать, но не изменять. Сервер запускается, работает и ломается при первой попытке сохраниться, обновить конфиг или переписать файл данных мода.

Решение - вернуть дерево служебному пользователю и больше не запускать в нём ничего от root:

# give the whole server folder back to the user it runs as$ sudo chown -R steam:steam /srv/valheim# run updates and edits as that user from now on$ sudo -u steam /home/steam/steamcmd/steamcmd.sh +runscript update.txt

Запускать саму игру от root, «чтобы не было проблем с правами», - неправильное решение. Тогда плагин с уязвимостью или вредоносный мод получает полный контроль над машиной, а не над одной папкой. Как запускать каждый сервер от собственного пользователя - что заодно не даёт файлам одного сервера быть доступными другому, - описано в статье несколько игровых серверов на одном VDS.

Владельцы в панели#

В панели на базе Pterodactyl вся эта категория проблем в основном исчезает. Демон запускает контейнер каждого сервера от одного непривилегированного системного пользователя, и папка сервера - включая всё, что вы загружаете через файловый менеджер или SFTP, - принадлежит этому пользователю. Ничто из того, что можно сделать через панель, не создаёт в папке сервера файл, принадлежащий root, так что ловушка root не срабатывает.

Владельца вы при этом тоже поменять не можете. chown требует root, внутри контейнера root нет, и опция «сменить владельца» в SFTP-клиенте завершится ошибкой Operation not permitted. Так задумано: на этом держится изоляция контейнера. Если владелец в листинге выглядит странно, обычно это SFTP-клиент показывает числовой id пользователя, для которого у него нет имени, а не настоящая проблема. Как устроены контейнеры и демон, объяснено в статье панель Pterodactyl простыми словами.

А вот режим в панели испортить по-прежнему можно.

Бит исполнения#

Shell-скрипту или нативному бинарнику для запуска нужен x. Когда его нет, ошибка прямолинейна:

/home/container/start.sh: Permission deniedbash: ./RustDedicated: Permission denied

Обычные причины:

• Файл загружен через браузер. HTTP-загрузка передаёт содержимое, а не права, поэтому каждый загруженный файл приходит с режимом 644.
• Файл из zip, созданного в Windows. В Windows нет бита исполнения, поэтому созданные там zip-архивы его не записывают. .tar.gz, созданный в Linux, режимы сохраняет; zip из Windows - нет.
• Файл отредактирован и сохранён инструментом, который его переписал, а не изменил на месте.

Решение - chmod +x на файл или установка режима 755. С shell это chmod +x start.sh. В панели используйте пункт прав в меню файла в файловом менеджере, если ваша панель его предлагает, или диалог Properties в SFTP-клиенте вроде WinSCP или FileZilla, который умеет задавать режим напрямую. Клиенты описаны в статье SFTP и файловый менеджер.

Есть похожая ошибка, которая выглядит как проблема с правами, но ею не является:

/bin/sh^M: bad interpreter: No such file or directory

^M - это окончание строки Windows. Скрипт сохранён с окончаниями строк CRLF, и Linux читает возврат каретки как часть имени интерпретатора. Переведите окончания строк в LF в редакторе (в большинстве есть настройка внизу окна) или командой dos2unix на своей машине. Никакая смена режима это не исправит.

Конфиги только для чтения: когда игра отменяет ваши правки#

Самая частая жалоба на конфиги игровых серверов - не «Permission denied», а противоположное: «я поменял настройку, а игра вернула её обратно». Почти всегда это игра переписала файл из своей копии в памяти.

Так делают несколько игр:

• Minecraft переписывает server.properties при запуске, добавляя недостающие ключи со значениями по умолчанию и выбрасывая ваши комментарии. Правьте его при остановленном сервере, а заметки о том, зачем задано значение, храните в другом месте.
• Project Zomboid переписывает .ini сервера при запуске и при изменении настроек в игре.
• Игры на Unreal Engine часто записывают свои файлы Saved/Config при выключении, так что правка, сделанная во время работы сервера, заменяется тем, что было в памяти в момент остановки.

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

Другой вариант - сделать файл доступным только для чтения через chmod 444, и у этого трюка есть пределы, которые стоит знать. Он действительно не даёт игре переписать файл. Но некоторые игры пишут ошибку в лог при каждой попытке его сохранить, некоторые отказываются запускаться, если не могут записать конфиг, а через полгода вы забудете, что файл только для чтения, начнёте его править и будете гадать, почему редактор не сохраняет. SteamCMD validate тоже не поможет, потому что восстанавливает только файлы, которые идут с игрой, а не те, что она создаёт. Если используете этот трюк, запишите это прямо в файле (# read-only on purpose, see admin notes) и применяйте только к файлу, про который известно, что игра терпит невозможность его записать.

Ошибки и что они означают#

Read-only file system заслуживает отдельного пояснения. Дело не в режиме какого-то одного файла: операционная система смонтировала весь том только для чтения, часто после обнаружения ошибки диска. Изнутри сервера это не исправить, и об этом нужно сразу написать хостеру в тикет.

Права панели: кто какие файлы может трогать#

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

Как это соотносится с реальной командой:

Две вещи стоит сделать правильно. Во-первых, доступ к файлам близок к полному доступу: любой, кто может править файлы, может отредактировать список админов, установить плагин или прочитать токен в конфиге. Выдавайте его так же осторожно, как доступ к консоли. Во-вторых, SFTP - отдельное право, потому что это самый мощный способ пользоваться остальными: целую папку можно скачать или заменить за секунды. Как проектировать роли, описано в статье субпользователи и минимальные права, а как защищать стоящие за ними аккаунты - в статье безопасность админских аккаунтов игрового сервера.

Файлы, которые вообще не должны быть доступны для чтения#

Некоторые файлы на игровом сервере - секреты: токен игрового сервера Steam в строке запуска или конфиге, лицензионный ключ FiveM в server.cfg, пароль базы данных в конфиге плагина, пароль RCON. На машине, которой вы управляете сами, дайте им режим 600, чтобы читать их мог только служебный пользователь. В панели главный рычаг - второй слой: у кого вообще есть право читать файлы. Помните также, что секреты оказываются там, куда вы их не клали: строки запуска, выведенные в логи, backup с конфигами, скриншоты файлового менеджера в Discord. Привычки, которые держат секреты на своём месте, описаны в статьях переменные окружения и секреты и безопасная работа с RCON.

FAQ#

Почему игровой сервер при запуске пишет Permission denied?

Обычно у скрипта запуска или бинарника пропал бит исполнения - часто после загрузки через браузер или распаковки из zip, созданного в Windows. Установите для файла режим 755 в SFTP-клиенте или файловом менеджере. Если же в сообщении указан файл данных, пользователь сервера не может записать в него или в его папку.

Может, просто сделать chmod 777 на всё?

Нет. Это делает каждый файл доступным для записи любому пользователю системы, а на общей машине или при скомпрометированном плагине это подарок. К тому же настоящую проблему это редко решает - обычно она во владельце или в одном отсутствующем бите исполнения.

Почему мой конфиг постоянно сбрасывается?

Игра переписала его из памяти - при запуске или при выключении. Остановите сервер, внесите правку и запустите его снова. Сделать файл доступным только для чтения в одних играх помогает, а в других вызывает ошибки.

Можно ли поменять владельца файлов на сервере в панели?

Нет, и это не нужно. Каждый файл в папке сервера принадлежит пользователю, от имени которого работает сервер, а для смены владельца нужен root, которого в контейнере нет.

Можно ли дать человеку доступ только к одной папке?

Большинство панелей выдают права на файлы на уровне сервера, а не папки. Если человек должен трогать только конфиг одного плагина, безопаснее всего вносить правки за него или дать ему тестовый сервер, где полный доступ ничему не навредит.