Ошибка su: must be suid to work properly появляется при попытке переключиться на другого пользователя командой su и означает, что у исполняемого файла su сброшен SUID-бит — специальный флаг, позволяющий запускать программу с правами её владельца (root). Без этого флага утилита физически не может повысить привилегии и отказывается работать, выводя именно это сообщение.
Чаще всего проблема возникает после некорректного копирования системных файлов, восстановления из бэкапа без сохранения прав, ручного «исправления» разрешений командой chmod или сбоя файловой системы. Реже виновником оказывается монтирование раздела с опцией nosuid. Ниже разберём, как диагностировать причину и безопасно вернуть su работоспособность.
Что такое SUID-бит и зачем он нужен команде su
SUID (Set User ID) — это специальный бит разрешений в Linux и других Unix-подобных системах. Когда он установлен на исполняемом файле, процесс запускается с правами владельца файла, а не с правами пользователя, который его запустил. Поскольку владельцем /bin/su является root, любой пользователь, запустивший su, временно получает возможность сменить учётную запись — конечно, после ввода правильного пароля.
Утилита su специально спроектирована так, чтобы отказываться работать без SUID-бита: это защитный механизм. Если бы программа запускалась без повышенных прав, она не смогла бы выполнить смену UID, а попытка работы в «половинчатом» режиме создала бы ложное ощущение безопасности. Поэтому вместо тихого сбоя вы видите понятное сообщение об ошибке.
Аналогично устроены и другие системные утилиты, требующие повышения привилегий: passwd, sudo, mount, ping (в некоторых дистрибутивах). Сброс SUID на любом из них вызывает похожие симптомы.
Как проверить права на файл su
Первый шаг диагностики — посмотреть текущие разрешения файла. Выполните в терминале:
ls -l /bin/suВ некоторых дистрибутивах файл располагается по пути /usr/bin/su, а /bin является символической ссылкой на /usr/bin — это нормально. Корректный вывод должен выглядеть примерно так:
-rwsr-xr-x 1 root root ... /bin/suКлючевой признак — буква s вместо x в блоке прав владельца (rws). Если вы видите -rwxr-xr-x без буквы s, значит, SUID-бит сброшен, и именно это вызывает ошибку.
- 🔍
-rwsr-xr-x root root— нормальное состояние, SUID установлен - ⚠️
-rwxr-xr-x root root— SUID сброшен, su работать не будет - ❓ Владелец не root — серьёзная проблема, возможно, файлы восстанавливались из бэкапа без сохранения владельцев
- 📁 Файл отсутствует — пакет утилиты мог быть удалён или повреждён
Восстановление SUID-бита: пошаговая инструкция
Для исправления потребуются права root. Возникает закономерный вопрос: как их получить, если su не работает? Варианты зависят от вашей ситуации: используйте sudo (если он настроен и работает), войдите в систему напрямую под root через консоль или экран входа, либо загрузитесь с Live-образа и примонтируйте корневой раздел.
Если у вас есть root-доступ любым из этих способов, выполните:
chmod u+s /bin/suЛибо эквивалентную числовую форму:
chmod 4755 /bin/suПосле этого снова проверьте права командой ls -l /bin/su — должна появиться буква s. Затем откройте новый терминал и проверьте работу su обычным образом.
☑️ Восстановление работы su
⚠️ Внимание: устанавливайте SUID-бит только на оригинальный системный файл su. Никогда не выставляйте SUID root на скрипты, самосборные программы или файлы, происхождение которых вы не уверены — это прямой путь к компрометации системы.
Если chmod не помогает: проверка опций монтирования
Бывает, что SUID-бит установлен корректно, но ошибка сохраняется. Тогда вероятная причина — корневой раздел (или раздел с /usr) смонтирован с опцией nosuid, которая глобально игнорирует SUID-биты на всех файлах раздела. Проверить это можно командой:
mount | grep -E ' / | /usr 'Или проще — изучите вывод findmnt / и findmnt /usr. Если в списке опций присутствует nosuid, нужно отредактировать /etc/fstab, убрать эту опцию для соответствующего раздела и перемонтировать его командой mount -o remount / или перезагрузкой.
Отдельный случай — системы в контейнерах (Docker, LXC) и окружениях с ограниченными возможностями. Там nosuid может быть задан на уровне хоста, и изменить его изнутри контейнера невозможно. В такой ситуации su внутри контейнера попросту не предназначен для повышения прав — входите в контейнер сразу под нужным пользователем.
Команда findmnt / показывает опции монтирования корневого раздела в удобном виде — быстрее, чем разбирать вывод mount вручную.
Проверка целостности пакета и альтернативные причины
Если права и монтирование в порядке, но ошибка осталась, возможно, сам файл повреждён или подменён. В дистрибутивах на базе Debian и Ubuntu целостность пакета проверяется так:
dpkg -V loginВ системах на RPM (Fedora, RHEL, CentOS) аналогичная проверка выглядит как rpm -V util-linux — точное имя пакета, содержащего su, зависит от дистрибутива. Если проверка показывает расхождения, переустановите пакет штатным менеджером пакетов — это восстановит и содержимое файла, и корректные права.
| Симптом | Вероятная причина | Действие |
|---|---|---|
| Нет буквы s в правах | Сброшен SUID-бит | chmod u+s /bin/su от root |
| Права верные, ошибка есть | Опция nosuid при монтировании | Правка /etc/fstab, перемонтирование |
| Владелец не root | Бэкап без сохранения владельцев | chown root:root /bin/su, затем SUID |
| Ошибка после восстановления прав | Повреждён или подменён файл | Проверка и переустановка пакета |
| Ошибка внутри контейнера | Ограничения хоста (nosuid) | Вход в контейнер под нужным пользователем |
⚠️ Внимание: если права на системные файлы сбросились «сами по себе», это повод проверить систему глубже — от сбоя файловой системы (fsck с размонтированного раздела) до признаков несанкционированного доступа. Единичный сброс SUID после ваших собственных действий с chmod или бэкапом — безобиден, массовые изменения прав — нет.
Почему бэкапы часто ломают SUID
Многие инструменты копирования (например, cp без ключа -a, некоторые архиваторы и облачные синхронизации) не сохраняют специальные биты разрешений и владельцев файлов. При восстановлении системы из такой копии все SUID-программы теряют свои флаги. Для системных бэкапов используйте rsync -aHAX, tar с правильными опциями или специализированные инструменты вроде Timeshift — они корректно сохраняют права, владельцев и расширенные атрибуты.
Массовая проверка SUID-файлов в системе
Если пострадал не только su, есть смысл найти все SUID-файлы и сравнить их список с эталонным для вашего дистрибутива. Поиск выполняется командой:
find / -xdev -perm -4000 -type f 2>/dev/nullОпция -xdev ограничивает поиск одной файловой системой, а 2>/dev/null скрывает ошибки доступа. В нормальной системе список невелик: su, sudo, passwd, mount, umount и несколько других утилит, точный набор зависит от дистрибутива и установленных пакетов.
Ошибка «su must be suid to work properly» почти всегда решается командой chmod u+s /bin/su от root. Если это не помогло — проверяйте опцию nosuid в опциях монтирования и целостность пакета.
Профилактика: как не столкнуться с ошибкой снова
Основные меры предосторожности просты и сводятся к аккуратной работе с правами и бэкапами:
- 💾 Используйте для резервного копирования инструменты, сохраняющие права и владельцев (
rsync -a,tarс запуском от root) - 🚫 Не применяйте
chmod -Rрекурсивно к системным каталогам — это типичная причина массового сброса SUID - 🛡️ Не добавляйте
nosuidв fstab для корневого раздела и/usr; эта опция уместна для/home,/tmpи съёмных носителей - 📋 Периодически сверяйте список SUID-файлов, если администрируете сервер — это одновременно и мера безопасности
Стоит понимать, что осознанный отказ от SUID на su — тоже легитимная практика жёсткой настройки безопасности (hardening): некоторые администраторы намеренно лишают su этого бита, оставляя только sudo с детальным журналированием. Если вы намеренно настраивали систему таким образом, ошибка — ожидаемое поведение, а не неисправность.
Часто задаваемые вопросы
Что означает ошибка su must be suid to work properly?
Утилита su обнаружила, что у её исполняемого файла отсутствует SUID-бит, либо раздел смонтирован с опцией nosuid. Без возможности запуска с правами root программа не может сменить пользователя и отказывается работать.
Как исправить ошибку, если su не работает и root-доступа нет?
Попробуйте sudo -i или sudo chmod u+s /bin/su, если sudo настроен. Если sudo тоже недоступен, войдите под root напрямую через консоль (Ctrl+Alt+F2) либо загрузитесь с Live-USB, примонтируйте корневой раздел и выполните chmod для файла внутри него.
Что означают права 4755 на файле?
Первая цифра 4 задаёт SUID-бит, а 755 — стандартные права: чтение, запись и выполнение для владельца, чтение и выполнение для остальных. Это штатный набор разрешений для /bin/su.
Опасно ли устанавливать SUID-бит?
На штатные системные утилиты (su, sudo, passwd) — нет, это их нормальный режим работы. На произвольные программы и скрипты — да: любой пользователь сможет запустить их с правами root, что создаёт серьёзную уязвимость.
Ошибка появилась после восстановления системы из бэкапа. Что делать?
Вероятно, инструмент резервного копирования не сохранил специальные биты разрешений. Восстановите SUID командой chmod u+s для пострадавших утилит, а для будущих бэкапов используйте rsync -a или tar от root, которые корректно сохраняют права и владельцев.