26

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

Пока что единственный каталог, через который он начал проходить, это /bin.

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

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

— Будет
источник

26

Похоже, тебя там покушали, приятель.

— ta.speot.is

4

Теперь вы понимаете важность резервного копирования. Делай это регулярно.

— Джулиано

По крайней мере, он не chmod от root. Это полная катастрофа. По крайней мере, rm -rf из root дает вам больше места на диске и подготавливает вас к полной переустановке системы, chmod просто оставляет настоящий беспорядок, из которого довольно трудно что-либо исправить, кроме полной переустановки системы. Трава коричневая с обеих сторон забора, а?

— Fiasco Labs

10

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

chown root:root -R /bin/

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

chmod 4755 /bin/su

— epic9x
источник

1

В Ubuntu особенно важно делать то же самое с sudo. Я не думаю, что пароль root даже установлен по умолчанию? Кстати, я бы действительно рекомендовал использовать sudo вместо корневых оболочек. Полсекунды, которые требуются для ввода sudo, обычно останавливают подобные ошибки в треках. Просто работать в корневой оболочке легче пропустить ...

— Бернд Хауг

4

paste.ubuntu.com/362468 - это «ls -l / bin» с моего рабочего стола Ubuntu 9.10. Хотя у меня могут быть не те же файлы, что и у вас, по крайней мере, это должно дать вам хороший совет, для каких файлов требуются специальные разрешения.

— Андол

@Bernd: Хотя я не делаю так много админской работы, я заметил, что у меня меньше глупостей, чем от имени root. Я никогда не смогу снова использовать пароль root. (И, нет, в Ubuntu нет пароля root по умолчанию, и я не думаю, что он есть в MacOSX.)

— Дэвид Торнли

@ Давид: Определенно нет пароля root по умолчанию на OS X, и установка его в большинстве случаев является ошибкой, IMO. Почти всегда есть другой, лучший способ. Проблема в том, что Mac не слишком безопасны для начала; Я ожидаю увидеть много «веселья», когда у них будет большая база для установки, чтобы сделать клиентов RK, Virii, Botnet и другие прибыльными.

— Бернд Хауг

36

Пользователь 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 систему, нет никаких причин, по которым вы не можете периодически выгружать файлы на другую машину и убедиться, что все работает.

— geocar
источник

Пользователь FreeBSD: никогда бы не допустил такой ошибки;)

— einstiien

10

@einstiien Да, пользователи FreeBSD выходят прямо на rm -rfсцену.

— Гравитация

@ Grawity: LOL, хорошо.

— einstiien

Бедные пользователи Solaris :(

— Мирча Chirea

3

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

— Тедди
источник

3

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

Но, в общем, вариант, который вы ищете, будет таким:

rpm --setugids {packagename}

— Coops
источник

Это в системе Ubuntu, как указано тегами. Это означает, что вместо rpm и .RPM используются dpkg и .DEBs

— Кевин М,

2

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

— ptman
источник

0

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

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

— Кристиан
источник

0

попробуйте это: найдите все 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 {} \;

— squillman
источник

0

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

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

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