Случайно запустил "chown www-data:www-data / -R" от имени пользователя root

Я просто запустил это несколько секунд назад, мне удалось сделать Ctrl-C, как только я понял, что я начал делать.

до сих пор в единственном режиссере его начали проходить через / бин

Я боюсь делать что-то еще, пока я понимаю, что больше не могу использовать "su" как мой обычный пользователь.

К счастью, у меня все еще есть другой корневой терминал, что делать?

8 ответов

Решение

Большинство всего в /bin/ должно принадлежать root:root, поэтому, если вы запустите следующее, вы можете исправить владение этими файлами:

chown root:root -R /bin/ 

Вы также можете убедиться, что бит setuid правильно установлен в /bin/su, что можно исправить с помощью следующего:

chmod 4755 /bin/su

Пользователь Redhat:

chown 0:0 /bin/rpm && rpm -qa | xargs rpm --setugids

Пользователь Debian/Ubuntu:

chown 0:0 /bin/*  /usr/bin/*
chown daemon:daemon /usr/bin/at
chown 0:utmp /usr/bin/screen
chmod 02755 /usr/bin/screen
chmod u+s /bin/fusermount /bin/mount /bin/su /bin/mount
chmod u+s /usr/bin/sudo /usr/bin/passwd
screen

Во время работы экрана сделайте это как минимум дважды:

dpkg --get-selections | awk '{ if ($2 == "install") print $1}' \
    | xargs apt-get install --reinstall --

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

Ускоренный курс на экране:

Control+A     - command key
Control+A a   - emit a control+A
Control+A n   - next "screen"
Control+A c   - create "screen"

Пользователь Solaris:

Вы трахались

pkgchk -R / -f -a

сбросит все разрешения, но setuid-ness все равно будет нарушен. Используйте резервную копию или другую машину Solaris, чтобы найти сценарии и файлы setuid / setgid и исправить их вручную.

ВАЖНАЯ вещь о резервных копиях

Разве что ты можешь их восстановить, а не то, что ты их берешь?

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

Я собирался объяснить детали использования RPM для сброса прав доступа к файлам, но я нашел сайт с гораздо большей информацией. В нем также упоминается, что Ubuntu/Debian (так..Debs в целом) не поддерживают его.

Но в целом вариант, который вы ищете, будет выглядеть следующим образом:

rpm --setugids {packagename}

Имейте в виду, что флаги set-uid на любых затронутых двоичных файлах также могут быть удалены; это особенность безопасности Чоуна. Уточните в какой-либо другой системе, какие двоичные файлы имеют флаги set-uid или set-gid, и убедитесь, что они установлены и в ваших двоичных файлах.

Если бы это была система Debian, я бы все переустановил.

У вас есть рабочая резервная копия? когда да, восстановите папку bin.

в противном случае, посмотрите на другую коробку, где вы установили ту же версию Ubuntu и chown к тому, что вы найдете на работающей установке.

Попробуйте это: найдите все www-данные в каталоге /bin

# find /bin -user www-data

затем измените www-данные обратно на первоначального пользователя

# find /bin -user www-data -exec chown ORiginalUser {} \;

# then change www-data back to oringal group
# find /bin -group www-data -exec chgrp originaluser {} \;

Спасибо всем за отличные ответы, кажется, все исправлено.

/ bin / su работал, когда chmod'd до 4755 (не уверен, почему chown изменил бит suid)

я не заметил, но он также начал работать через каталог /home, но это было достаточно легко исправить (просто установите user:group для пользователя для каждого каталога)

Другие вопросы по тегам