Права доступа в Linux это первое с чем приходится знакомиться каждому новому пользователю и не все гайды дают полную картину происходящих в системе процессов.
Предисловие
На Хабре уже есть замечательная статья о правах доступа, здесь же я хотел описать то , что произойдет в вашей системе после
chmod -R 777 /
Основная часть
Для новичка может показаться что задавая и возвращая права обратно никакого ущерба системе нанести не получится, ведь мы все вернули как было. Итак с полной уверенностью в своих действия мы вводим команду и присваиваем все права всем файлам в системе. Что может пойти не так?
1. Мы навсегда распрощались с безопасностью
Чтож, это был осознанный риск и вопрос безопасности нас мало волновал останется ли система работоспособной?
2. Первая вереница ошибок
Команды sudo, sendmail и ряд других просто перестанут работать. Суть в том что эти команды проверяют разрешения ключевых файлов, видят что они отличаются от ожидаемых и выдают ошибку.
3. 777 на самом деле 0 777
Старший бит это биты setuid и setgid. Они необходимы для запуска файлов с определенными привелегиями. Теперь этот бит 0 , а это несомненно приведет к бесчисленному количеству ошибок.
4. /tmp и /var/tmp серьезно пострадали
В правах доступа есть sticky bit он защищает файлы от удаления людьми не владеющими ими. Это необходимо, т.к. некоторые скрипты очищают директории /tmp и без установленного sticky bit мы распрощаемся со всеми файлами в этом каталоге.
5. Теперь каждый файл в вашей системе исполняемый.
Да, теперь каждый файл в вашей системе исполняем, а для недобросовестных людей это бесконечные возможности. Можно с легкостью заставить нас запустить вредоносный код, назвав его именем команды и это только малая часть возникающих рисков.
А можно ли починить систему?
Теоретически да, но скорее в учебных целях. Если нам нужна полноценно и безотказно работающая система самым рациональным выходом будет полная переустановка, или откат на существующий backup. Таким образом неосторожное обращение с ,казалось бы, известной нам командой может привести к большому количеству проблем.
Комментарии (17)
13werwolf13
04.03.2022 08:16+1А можно ли починить систему?
Теоретически да, но скорее в очебных целях.
ЕМНИП, на самом деле можно сделать это относительно безболезненно в некоторых дистрибутивах из коробки идёт пакет содержащий в себе файлик со списком прав на ключевые для системы файлы и директории, и скрипт который парсит и применяет их. Ну и наверное полная переустановка всех пакетов тоже всё пофиксит на уровне системы, а вот в хомяках и data директориях некоторого софта придётся прибраться руками..
kosbic
04.03.2022 11:49в некоторых дистрибутивах из коробки идёт пакет
а можете написать пример такого пакета? быстрым поиском гугла я не нашел ничего подобного
13werwolf13
04.03.2022 12:02-1Так с ходу не расскажу, напрямую не сталкивался, мне это рассказывали сколько-то лет назад, ну в opensuse видел при обновлении системы пакеты permissions и permissions-config, возможно это как раз оно.
ne555
04.03.2022 08:27+4откат на существующий backup
А ещё пользователь не так давно перешёл на GNU/Linux, сделал свой бэкап ранее в криптоконтейнер, например, Veracrypt (том fat32/ntfs). Права все утеряны. Система восстановлена, но не работает. Фэйл.
На полноценную статью материал не очень тянет, плюс орф.ошибки.
alexander222
04.03.2022 08:44+4Да, жизненно. Сделал так по юности на удаленном сервере, думал что безопасность не так критична, а не заморачиваться с правами сэкономит кучу времени. Спас бэкап, который удачно был снят не за долго перед этим. Второй подобный эпичный раз был немного позже, когда я выполнил chmod -R 777 на свою домашнюю директорию что бы nginx мог запускать из нее скрипты, и с удивлением обнаружил что больше не могу зайти по ssh. Благо там был добрый админ, который пообещал оторвать мне руки, и отобрать права на все сервера пока не соберу сам linux from scratch.
ubriaco
04.03.2022 12:38Была подобная ситуация, тоже не мог зайти по ssh. Благо дело было в облаке, примонтировал этот диск к другой машине и смог все исправить.
sergiks
04.03.2022 09:46-2Хороший материал может получиться, если продолжить опубликованное вступление.
Уверен, что полезная для многих тема.
Меня чуть разочаровала краткость. Я был готов воспринять какие-то более глубокие ньюансы, с которыми раньше не сталкивался.
slepnoga
04.03.2022 10:13+2Не 0 777, а на на самом деле 00 777.
Но если копнуть больше, то обнаужим, что место зарезервировано для 8 разрядов.
Р.S. Вспоминая Федорчука и нынешний "контент" :(((
unsignedchar
04.03.2022 10:16Пожалуй, действительно, можно было бы развить эту тему. То, что эта команда сломает чуть более чем всё - нет возражений. Но можно было бы и попробовать восстановить систему - это было бы более полезно.
saboteur_kiev
04.03.2022 16:41неосторожное обращение с ,казалось бы, известной нам командой может привести к большому количеству проблем.
Неосторожное обращение - это права администратора у неграмотного пользователя.
С админским доступом, поломать систему можно и более простыми способами, чем запускать консоль и вводить там команды...
lexore
04.03.2022 23:54Фигня, без sudo ничего не случится. Вы же не логинитесь под рутом на сервер? :)
Tangeman
05.03.2022 02:49Я логинюсь, лет 25 уже как. Потому что в 99.9% случаев когда я логинюсь мне нужны права рута — и за всё это время ни одного фейла, как ни странно.
Как обычный пользователь я логинюсь только для сборок, разработки, офисых задач (под иксами) а также в случаях когда что-то в песочнице нужно погонять, или если у клиента нет рутовских прав (или они не нужны).
Вообще непонятно откуда эта мантра "не логинтесь как рут" — разве что для чайников (как слабая защита от фейлов), потому что даже во времена telnet на небезопасной сетке sudo/su не спасало от прослушки и последующего вредительства.
Впрочем, как показывает практика, от любителей стрелять себе в ногу не спасают даже бронештаны с бронеботинками — если человек не знает что делает, не выспался, или тупо повторяет инструкции шутников, в этом случае его всё равно не спасёт логин обычным пользователем если команда требует sudo.
saboteur_kiev
06.03.2022 01:41без sudo получить рутовый доступ в нормальной системе можно только в single режиме. Ибо пароль у рута должен отсутствовать по определению.
unsignedchar
06.03.2022 08:11Если система пару лет не обновлялась - скорее всего, найдутся и другие способы.
Akina
Бит - это биты. Какая-то не очень удачная формулировка... таки "старший байт содержит/хранит/включает биты setuid и setgid", вероятно?