Иногда это не наши друзья, мы - наши собственные худшие враги

Я записал, что сценарий к паролю защищает rm как OP требуемые, но также и вставленные редактирования для предотвращения Вас от случайного удаления:

• /
• / домой
• / мусорное ведро

Править: 5 марта 2017 - метод Изменения проверки при выполнении в терминале.

Создайте сценарий

Использовать gksu gedit /usr/local/bin/rm и копия в этих строках:

#!/bin/bash

tty -s;
if [ "0" == "$?" ]; then Terminal="Y"; else Terminal="N"; fi

if [ $Terminal == "Y" ] ; then
    # Running from terminal don't allow delete of / or /toplevel directory even if sudo
    for i in ${@:1}
    do
        # Skip options -i -r -v -d 
        if [[ ${i:0:1} != "-" ]] ; then
            # if parameter doesn't begin with '-' it's file or directory, so get real path.
            fullname=$(realpath "$i" 2>&1) # No error messages if file doens't exist
            # We must have at least two `/` in the full path
            levels=$(echo "$fullname" | tr -cd '/' | wc -c)
            if (( $levels == 1 )); then # Test for 1, will be zero when file doesn't exist.
                echo "Attempting to remove top level directory '$fullname'"
                echo "Use 'sudo /bin/rm $@' instead."
                exit 1 # error
            fi
        fi
    done
fi


if [[ $(id -u) != 0 ]]; then # Only non-root processes enter password (ie "sudo rm ..." is ok)
  if [ $Terminal == "Y" ] ; then
  # Only running from a terminal needs password (ie not cron)

    # log rm usage to /var/log/syslog
    PARENT_COMMAND="$(ps -o comm= $PPID)"   
    logger "$PARENT_COMMAND"" - rm command was used on file: ""$fullname"

    # Get password
    Password=$(zenity --password --title="Password for rm")
    encryptPassword=$(echo -n "$Password" | md5sum)

echo "md5sum: $encryptPassword" # Comment out after viewing one time and updating line below.

    if [[ "$encryptPassword" != "d2c30dc65e59558c852ea30b7338abbe  -" ]]; then
        echo "Invalid password!"
        exit 1
    fi
  fi # non-terminals can't enter password.
fi # root doesn't need to enter password.

# Call REAL rm command with parameters passed to this wrapper sript
/bin/rm "$@"

exit 0

Измените пароль "WE2U" на что-либо, что Вы любите и сохранили файл.

Новый Mark rm сценарий как исполняемый файл

Новый флаг rm сценарий как исполняемое использование:

sudo chmod +x /usr/local/bin/rm

Как это Работы

Если пароль не является WE2U, в первый раз, когда Вы запускаете скрипт, Вы получите "неверный пароль" и ключ шифрования для пароля, который Вы ввели, отображен. Скопируйте и вставьте этот ключ шифрования от терминала в сценарий. Затем прокомментируйте строку с эхом, которое отобразило ключ шифрования на терминале.

Поскольку путь /usr/local/bin выше в списке, чем /bin наша команда rm назван. После получения действительного пароля это звонит /bin/rm сделать реальное удаление.

Как Thomas Ward указал в другом ответе, если необходимо было сделать a sudo apt-get install ... Вас можно было попросить пароля тысячу раз. Сценарий проверяет если sudo используется и не просит пароль. Кроме того, если rm назван из приложения GUI, никакой пароль не требуется.

Вызовы сценария logger записывать каждый раз rm был вручную назван с помощью терминала. Использование команды зарегистрировано к /var/log/syslog.

У меня есть подобная возможность, что я запланировал. На файловом сервере, если оперативная память фотографий перезаписываема, что кто-то в семействе (менее технический или случайно) мог бы удалить что-то, случайно притянуть gui, который перемещает каталог, или перезаписывают оригинал с отредактированной версией вместо переименования.

я понял, что могу защитить от этого, не делая полномочия неперезаписываемыми для всех остальных. ZFS делает периодические снимки так любое случайное удаление, или перезапись может быть инвертирована. (В отличие от резервного копирования, снимок легок и копия на записи так это, doesn’t умножают Ваше использование хранилища.)

ZFS является собственным к FreeBSD. Linux имеет btrfs, который также имеет снимки.

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

Однако Вы могли использовать псевдоним для изменения способа, которым ведет себя команда комнаты. Попробуйте:

alias rm="sudo -l >/dev/null && rm"

то, Что это делает, - когда кто-то вводит команду комнаты, она выполняет sudo-l команда. Эта команда вынуждает пользователя ввести их пароль. Если они разбираются в нем, это перечисляет их полномочия (мы отбрасываем этот вывод), и выходы с состоянием 0, если они понимают его превратно, это существует с ошибкой.

Мы затем следуем за командой sudo с "& &"; который выходит из следующей команды - в этом случае "комната", только если предыдущая команда выходит с состоянием 0 - т.е. они разобрались в пароле.

Для создания этого постоянным включайте команду псевдонима в ~/.bashrc.

Примечание это это очень легко побеждено (например, они могли просто тип /bin/rm.

Другая альтернатива должна была бы создать резервные копии любых важных файлов в каталоге, к которому у некорневых пользователей нет доступа. Вы могли использовать rsync или unison для синхронизации их автоматически, просто удостоверьтесь, что по крайней мере один каталог в пути к резервному месту назначения принадлежит корню и режиму 700. Это привело бы к наличию двух копий всех файлов все же. Было бы более безопасно просто создать гостевого пользователя для них для использования, кроме Вас действительно должны не забыть всегда блокировать или выходить из системы прежде, чем дать им компьютер или оставить это необслуживаемым.

Можно изменить полномочия на /bin/rm команда через следующую строку, которая предотвратит то, чтобы он был выполняемым без sudo доступа:

sudo chmod 750 /bin/rm

Это конкретно препятствует тому, чтобы они использовали rm команда обеспечивается системой. Необходимо знать, что это не препятствует тому, чтобы они удалили файлы другими способами.

Также препятствовать тому, чтобы они использовали rmdir команда, которая является распространенным способом удалить каталоги, можно установить полномочия тот же путь на его исполняемом пути:

sudo chmod 750 /bin/rmdir

Напомните, что также можно только использовать, это управляет с sudo правами также.

Возвращать его, если Вы не как он или другие проблемы происходите использование 755 для chmod

Поскольку @muru указал, что вышеупомянутое является очень сырым решением и могло бы даже повредить системные службы, которые не работают на корневой учетной записи. Поэтому я добавляю здесь другую опцию с помощью ACL (списки управления доступом), чтобы сделать то же и вероятно намного более безопасный (хороший для чтения в также, и можно пропустить часть включения, потому что ACL обычно устанавливается в системах Ubuntu в наше время):

Таким образом, чтобы сделать то же как выше только для пользователей, которых Вы хотите заблокировать, было бы

sudo setfacl -m u:<user-name>:- /bin/rm /bin/rmdir

Просто замена <user-name> с фактическими именами пользователей Вы хотите предотвратить использование файлов.

Как с chmod, использование setfacl -m препятствовать тому, чтобы определенные пользователи работали rm и rmdir относится к тем обеспеченным системой, управляет только. Это не мешает им удалять Ваши файлы и папки в Наутилусе или при помощи других терминальных команд.

Объяснение:

• -m отметьте означает изменять файлы ACL.
• первая часть изменения, u поддерживает пользователя. Это может иметь следующие значения u для пользователя, g для группы и o для всех других
• средняя часть <user-name> может пристанище фактическое имя пользователя или название группы согласно тому, что Вы хотите изменить. Для установки полных изменений, Вы оставляете это пустым.
• третья часть содержит вид полномочий, которые Вы хотите установить. Здесь в примере мы хотим не установить полномочия вообще, таким образом, мы помещаем -, это может также содержать следующие буквы r для полномочий чтения, w для полномочий записи и x для выполнения.

Нет никакого простого способа настроить такой пароль на rm сама команда, не без большого взламывания кода это, вероятно, повредит вещи как apt-get установка пакетов и удаление файлов и создание Вас должны ввести пароль тысячу раз или потенциально разрушение доступа к команде людям, которым был бы нужен он (как Вы, для удаления собственных файлов). Можно отсортировать, делают это при наличии многопользовательского доступа к счету и наборов полномочий множественного доступа и ограничения доступа к различным разделам данных, таким как корневой каталог, таким образом, они не могут добраться до него.

(Другая опция является счетами отдельного пользователя на каждого пользователи и затем Списки управления доступом, как детализирован в другом ответе, который был отправлен Videonauth),

Вот базовая проблема - Вы позволяете своим друзьям использовать Вашу систему. Это имеет многочисленные последствия безопасности - понятие "любого с физическим доступом к полю будет способным управлять системой и сделать, любыми задачами" является Молитва Безопасности IT-систем, которая является, почему Вы не 'совместно используете' физический системный доступ кроме с доверяемым авторизованным персоналом.

Единственный действительно нормальный способ сделать это не должно предоставить Ваших друзей доступ к Вашему компьютеру и дать им 'специализированную "Гостевую" систему', которую они могут использовать, на котором Вы действительно не заботитесь о файлах так же. Это - самый 'безопасный' способ бережно хранить Ваши файлы.

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

Это - то, как Вы сделали бы это:

Скажем, моим именем является "Нечто", и я хочу, чтобы пользователь "Панель", друг, использовал мою систему, но не получил доступ к моим файлам. Первый шаг должен запретить доступа к любому, но меня к моему корневому каталогу. Это должно разрешить другим пользователям не удалять Ваши файлы, но также препятствовать тому, чтобы другие пользователи шпионили вокруг в Вашем корневом каталоге и видели, какие типы материала Вы вошли в свой корневой каталог:

chmod 750 /home/Foo

Второй шаг должен создать учетную запись пользователя для "Панели" (НЕ вводите то, что находится в круглых скобках ниже, это только в информационных целях). Таким образом, мы можем удостовериться, что у него есть свой собственный отдельный набор прав доступа:

sudo adduser --create-home --user-group --shell /bin/bash Bar
sudo passwd Bar
(set a temporary password - you will not see characters as you type though)

Третий шаг должен затем ограничить их корневой каталог также, таким образом, никто не может совать нос в их файлы также. Это просто делает вещи равными.

sudo chmod 750 /home/Bar

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

ВСЕГДА ПОМНИТЕ ЭТО: Путем предоставления кому-то физического доступа к машине или доступа в целом, Вы собираетесь подвергнуть опасности свои файлы и данные. Это - широко принятый факт в мире Безопасности IT-систем и тот, который продолжает сохраняться. При предоставлении друзей доступ к компьютеру будет всегда подвергать данные опасности, таким образом, или дадут им их собственную систему для бездельничания с или просто не предоставляют им доступ к машине.

Просто примечание по шифрованию диска

В то время как шифрование диска работает хорошо для защиты данных от третьего лица, существуют ограничения.

1. Если система идет, диск уже дешифрован, таким образом, Вы находитесь в опасности.
2. Некоторые системы повредили подходы шифрования диска. Например, некоторые системы Acer используют Ваш пароль, чтобы только авторизовать шифрование/дешифрование и использовать трудно кодированные пароли или использовать слабое шифрование, которое легко взламывается.
3. Всегда существуют методы, чтобы ворваться в 'ключи' или попытаться извлечь их из памяти сразу после того, как система выключена, но прежде чем данные RAM не стали или ухудшились. (Я не пойду подробно на них, но эти риски действительно существуют).
4. Физический доступ к машине, шифруется ли система или нет, будет всегда подвергать Ваши данные опасности. Не предоставляйте физический доступ (или удаленный доступ к сети) людям, к которым Вы не хотите потенциально предоставлять полный доступ к своей системе.

В то время как Шифрование диска не решает эти проблемы, оно помещает дополнительные слои головных болей для агента угрозы. Кто-то, кто плохой парень, мог бы сдаться, если это шифруется, или они могут подвергнуть пыткам Вас (очередь обязательный комикс безопасности XKCD).

Поэтому, если Ваша система шифруется, но Вы позволяете другим пользователям использовать ее, у или их есть пароль для дешифрования, или Вы оставляете свой ноутбук дешифрованным, таким образом, они могут SSH в или иметь физический доступ. В обоих этих случаях это плохо.

Тем не менее, если Ваша система не шифруется, то этот раздел не имеет никакой уместности для Вас.

Не прямой ответ на вопрос Вы ищете, но:

, Если Ваши друзья удаляют Ваши файлы с помощью эти rm команда затем любой Ваш, друзья или некомпетентны, толчки, или они BOFH подражатели, которые пытаются учить, что Вы для не отъезда сессий вошли в систему и необслуживаемый. Во всех случаях решением является то же: не уезжают, Ваша сессия вошла в систему и необслуживаемый .

Это имеет преимущество не необходимости не забыть вносить специальные изменения в систему каждый раз, когда Вы обновляете или получаете новую систему, и также предотвращает сценарии и другие вещи, которые Вы используете, которые полагаются на команды, ведущие себя как ожидалось от сбоя непредсказуемыми способами.

Это также имеет преимущество останавливающихся "друзей" от хождения дальше до следующего шага. Вы также захотите к "паролю, защищают" эти mv команда, если они решают переместить Ваши файлы в/dev/null, когда они узнают, что простое удаляет, не делает то, что они хотят? Когда Вы находитесь в игре как это, единственное перемещение победы не должно играть.

Если бы Вы хотите к паролю - защищают комнату, решение состояло бы в том, чтобы сделать обертку для комнаты, которая потребовала бы полномочий пользователя root и попросила бы пароль иначе. (ОТМЕТЬТЕ: Эта обертка может уйти, когда coreutils пакет обновляется или переустанавливается.) Кроме того, обратите внимание, что это только защищает комнату, существуют все еще многие, много других способов удалить файл.

Откройте терминальное и станьте корнем. Затем выполненный sudo mv /bin/rm /bin/rmold перемещать старую комнату в другое место.

Теперь выполненный sudo nano /bin/rm создать обертку.

В Нано введите следующее:

#!/bin/bash
/bin/rmold "$@"
exit "$?"

Затем держите CTRL, и нажмите X выходить.Пресса Y когда Вам предлагают, затем совершаете нападки ENTER сохранить файл.

Наконец, мы должны дать этому соответствующие полномочия:

sudo chmod a+x /bin/rm

И там Вы идете.

Очень глупое обходное решение для очень глупой проблемы.

, Если Вы не хотите к chmod rm, rmdir, или mv (для mv filename /dev/null) или используете ACLs, Вы могли создать фиктивного пользователя с паролем, который никто, но Вы не знает, и исказите каждую команду к sudo [user] и затем сделайте псевдонимы для каждой команды, которую не знают Ваши друзья. Таким образом, когда Ваши друзья тип rm система запросит их пароль (но предположение пароля неправильно зарегистрирует неудачную попытку), и Вы можете все еще просто тип rmalias или независимо от того, что Вы принимаете решение на самом деле удалить файлы.

Или Вы могли просто создать гостевую учетную запись, которая не имеет доступа к Вашему корневому каталогу.

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

Необходимо ли управлять доступом или просто предотвратить ли честные ошибки?

Принятие Ваших друзей знает, что Вы не хотите, чтобы они удалили Ваши файлы, существует две возможности:

1. Они могли делать его нарочно. В этом сценарии Ваши друзья сознательно удаляют Ваши файлы, и Вы не можете даже доверить их, чтобы попытаться выполнить Ваши пожелания о том, как они рассматривают Ваши данные, когда они используют Ваш компьютер. Единственное решение этой проблемы состоит в том, чтобы использовать фактическую эффективную меру безопасности, как Thomas Ward объяснил подробно. Часто лучшее такая мера должно помешать им использовать Ваш компьютер. Но создание их использовать их собственные учетные записи пользователей может обеспечить некоторую защиту.

2. Они могли делать его по ошибке. В этом сценарии Ваши друзья являются чрезвычайно невезучими, и они продолжают бежать rm команды им жаль, что они не имели. Они хотят рассматривать Вас и Ваши данные с уважением, но действительно плохи при выполнении так на практике, потому что они продолжают управлять неправильной командой, удаляя неправильный файл... или что-то как этот. Хотя было бы хорошо полагать, что это - то, что происходит, я предостерегаю Вас против предположения, что люди, которые продолжают удалять Ваши данные после того, как Вы сказали им останавливаться, действуют без неприязни.

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

Если ситуация действительно является № 2 - Ваши друзья не пытаются удалить Ваши файлы, но просто нуждаться в помощи, не случайно удаляя их, и единственный способ, которым они когда-либо случайно удаляют их, через непреднамеренное неправильное употребление небольшого количества команд (как rm) то, что они испытывают особые затруднения с помощью правильно - затем, методы в ответе Videonauth могут быть несколько полезными. Но необходимо понять, что они не меры безопасности, потому что rm команда является только одним из многих простых способов удалить файлы. Посмотрите ниже для деталей.

Я рекомендую спросить себя, "Моя ситуация в основном то же, как будто я, а не другие люди, которые используют мой компьютер, был использованием того rm неправильно?"

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

• Образование. Ваши друзья должны знать то, что они делают и как избежать его.
• Интерфейсные изменения. Не устраняя фактическую способность удалить файлы (который требует учетных записей отдельного пользователя), можно мешать случайно удалять файлы путем создания этого поэтому просто выполнением rm file отдельно, без дальнейшего действия, сразу не удалит file. Ответ Videonauth дает один подход к этому. В этом ответе я представляю другого.

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

Создание rm подсказка перед удалением может помочь предотвратить некоторые ошибки.

Помочь людям постараться не случайно удалять файлы с rm, можно сделать rm псевдоним оболочки, который на самом деле работает rm -i. Передача -i флаг к rm причины это для запроса пользователя прежде, чем удалить каждый файл (см. man rm).

Вы могли сделать это (для Вашей учетной записи пользователя) путем добавления alias rm='rm -i' к Вашему .bash_aliases или .bashrc файл. Посмотрите этот вопрос и что один для деталей. Это вступит в силу для Ваших недавно открытых оболочек удара.

Это не обеспечивает фактической безопасности и не является надежным при предотвращении ошибок также, потому что:

• Они могут принять решение продолжить удаление при запросе.
• Они могут обойти псевдоним многочисленными способами, включая путем выполнения /bin/rm или неискажение его (unalias rm).
• Существует много ситуаций, где расширение псевдонима не происходит, и в этих ситуациях rm не будет выполнен с -i.
• Они могут все еще удалить файлы при помощи любого из методов, чтобы сделать так, чтобы не требовали rm (как имеет место с подходом Videonauth - посмотрите ниже).
• Они могут все еще повредить данные, не удаляя файлов, такой как путем перезаписи их или иначе изменения их содержания (поскольку также имеет место с подходом Videonauth).

Но если Вам не нужна фактическая безопасность (см. выше), затем это могло бы быть способом пойти. Для сравнения к подходу препятствования тому, чтобы Ваши друзья использовали обеспеченный системой rm команда:

• Искажение rm кому: rm -i является менее эффективным при предотвращении ошибок - пока они не идут дальше к использованию некоторой другой техники для удаления файлов. В той точке, мешая им использовать rm будет совершенно неэффективно, даже если они не попытаются сделать что-то не так, то так как, по-видимому, они будут использовать unlink (или любая из бесчисленных других команд, которые удаляют файл) с равной неосмотрительностью.

• С другой стороны, потому что расширение псевдонима только происходит в некоторых ситуациях - примерно разговоре, обычном интерактивном использовании оболочки - Ваши друзья могли бы думать, что они собираются быть запрошенными, когда они действительно не запрашиваются (потому что команда находится в сценарии, например, или выпущена от другой оболочки). Путь Videonauth не имеет этой проблемы, которая является объективным преимуществом того законченного метода alias rm='rm -i'.

• Когда сценарий работает, если он не записан сознательно для использования псевдонимов, псевдонимы не расширены в нем. Это означает то искажение rm кому: rm -i очень вряд ли повредит что-либо. Это - объективное преимущество alias rm='rm -i'.

rm не может сделать ничего, что любая другая совершенно обычная программа не могла сделать.

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

Несколько команд выполняют некоторую задачу, которую ограниченный (некорневой) пользователь не может выполнить, не выполняя их. Например, sudo позволяет Вам запустить программы как другому пользователю, после проверки, чтобы гарантировать, что Вам разрешают сделать так. passwd редактирует базу данных, где пароли пользователей хранятся, но только позволяет Вам изменить свой собственный пароль (если Вы не корень, в этом случае можно изменить чей-либо пароль).

/usr/bin/sudo и /usr/bin/passwd может сделать это, потому что у них есть setuid набор битов, как показано s это появляется в крайнем левом столбце, когда Вы работаете ls -l:

ek@Io:~$ type -a sudo passwd rm
sudo is /usr/bin/sudo
passwd is /usr/bin/passwd
rm is /bin/rm
ek@Io:~$ ls -l /usr/bin/sudo /usr/bin/passwd /bin/rm
-rwxr-xr-x 1 root root  60272 Feb 18  2016 /bin/rm
-rwsr-xr-x 1 root root  54256 Mar 29  2016 /usr/bin/passwd
-rwsr-xr-x 1 root root 136808 Aug 17 09:20 /usr/bin/sudo

Заметьте это /bin/rm имеет нет s: его полномочия -rwxr-xr-x, в то время как /usr/bin/passwd и /usr/bin/so иметь -rwsr-xr-x вместо этого. Это делает его так, чтобы, неважно, кто работает passwd или sudo, это на самом деле работает как пользователь root, так как корень является владельцем исполняемого файла. (Существует также бит setgid, который, когда установлено, заставляет исполняемые файлы работать с идентификационными данными группы их владельца группы, а не той из вызывающей стороны.)

За исключением любых уязвимостей системы обеспечения безопасности, которые еще не были обнаружены (или которые были обнаружены, но еще не были исправлены), sudo и passwd безопасны, потому что те утилиты очень тщательно записаны так, они могут только сделать вещи, которые вызывающей стороне нужно разрешить сделать.

/bin/rm не прокладывает себе путь. Это не setuid, потому что это не должно быть. Полномочия каталога (и иногда полномочия файла) управляют тем, какие файлы пользователь может удалить, и они не должны становиться корнем, чтобы сделать это. Только, чтобы быть совершенно ясными, никогда не устанавливайте setuid, обдумал rm. Последствия безопасности имели бы катастрофические последствия, с тех пор, неважно, кто работает rm, это - как будто корень выполнил его! (Утилиты как sudo и passwd проверьте, кто действительно выполняет их, и проверьте, что что-то разрешено прежде, чем сделать его; rm не делает такой вещи.)

Проверка, установлен ли setuid (или setgid) бит на исполняемом файле, скажет Вам при ограничении, кто может работать, это получает возможность повышения безопасности. Исполняемые файлы, которые не являются setuid (или setgid) не имеют никакого особого статуса, и любой может просто скопировать их и выполнить копию, принести их собственную копию с другой машины, записать сценарий или программу, которая делает то же самое или использует другую программу, чтобы сделать это.

Удаление файлов без rm

Очевидный способ удалить файл без rm в Ubuntu должен перейти к его местоположению в браузере графических файлов (Наутилус, если Вы используете Единицу или GNOME Shell), и удалите файл. Существуют также многочисленные команды, которые могут использоваться для удаления файла из терминала без когда-либо использования rm.

Например, для удаления названного файла foo.txt в текущем каталоге, следующих командах, которые работают out-of-the-box над Ubuntu и не требуют доступа к rm, достигнет этого. (Только, чтобы быть уверенным, я протестировал их в 16,04 минимальных системах, установленных только со стандартными системными утилитами после удаления /bin/rm.)

• unlink foo.txt
• busybox rm foo.txt
• perl -e 'unlink("foo.txt")'
• python3 -c 'import os; os.remove("foo.txt")' (python вместо python3 в более старых выпусках)

Тот список нигде не, конечно, рядом полон. Никакой полный список таких команд не возможен. Предотвращение удаления файла является одной из вещей, которых учетные записи отдельного пользователя и файл и полномочия каталога существуют для достижения. Они работают очень хорошо для предотвращения его. Напротив, изменение rm команда (чтобы заставить его потребовать пароля, или любым другим способом) или доступ ограничения к rm не предотвращайте его вообще.