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

Как сказал @ctt, вероятно, хорошей идеей будет сначала запустить его в какой-нибудь песочнице. Использование ВМ, вероятно, самое простое решение. Multipass довольно прост.

Установите мультипасс (если вы еще этого не сделали):

sudo snap install multipass --beta --classic

Раскрути новую ВМ:

multipass launch --name myvm

Войдите в свою новую виртуальную машину:

multipass shell myvm

Затем запустите ваш скрипт (внутри вашего vm):

multipass@myvm:~$ git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh

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

Тем не менее, мы можем помочь вам расшифровать код построчно. Для кого-то здесь, вероятно, нецелесообразно анализировать весь код.

На самом деле у вас есть 40 bash-скриптов с общей суммой в 5 360 строк. Я объединил их вместе и искал команды bash/shell, которыми можно злоупотреблять. Все они, кажется, используются нормально:

$ cat /tmp/sshellcheck.mrg | grep " rm "

      rm -rf "$RETURNPATH"/tmp/*
      rm -f "$RETURNPATH"/.mynorminette
    rm -f $LOGFILENAME
    rm -f $LOGFILENAME
      rm -f .mymoulitest
        rm -f "${RETURNPATH}/tmp/${FILEN}"

$ cat /tmp/sshellcheck.mrg | grep -i kill

  function check_kill_by_name
          kill $PROCESSID0
  declare -a CHK_MINISHELL_AUTHORIZED_FUNCS='(malloc free access open close read write opendir readdir closedir getcwd chdir stat lstat fstat fork execve wait waitpid wait3 wait4 signal kill exit main)'
        check_kill_by_name "${PROGNAME}"
      kill -0 "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null && kill "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null
      display_error "killed pid: ${CURRENT_CHILD_PROCESS_PID}"
    check_kill_by_name "$PROGNAME $PROGARGS"
        check_kill_by_name "$PROGNAME $PROGARGS"
        kill ${PID} 2>/dev/null

$ cat /tmp/sshellcheck.mrg | grep -i root

      "check_configure_select ROOT" "Root folder:          /"\
      'ROOT')
        echo "'${ALLOWED_FILES}' must be placed at root folder but was found here:" >>"${LOGFILENAME}"
        printf "%s" "'${ALLOWED_FILES}' must be placed at root folder"

$ cat /tmp/sshellcheck.mrg | grep -i sudo

$ 

• Здесь нет rm -rf / Команда стереть весь раздел жесткого диска.
• Там нет требования, что sudo быть использованы для запуска сценария.
• На самом деле скрипт проверяет только авторизацию C функции используются в проверенных файлах.
• Быстрый просмотр кода bash/shell показывает, что он написан профессионально и прост в использовании.
• Использование shellcheck для объединенных включаемых файлов выявляет только три синтаксических ошибки.
• Имена авторов определены, и у основного автора даже есть его изображение на его github стр.
• Хотя в жизни нет никаких гарантий, 42FileChecker кажется безопасным для использования.

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

Оригинальный ответ

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

Также спросите автора:

• Какие файлы обновляются?
• Что происходит, если происходит сбой из-за сбоя питания или программной ошибки?
• Можно ли сначала выполнить мини-резервное копирование?

И любые другие хорошие вопросы, которые вы можете придумать.

Редактировать 1 - Беспокойство по поводу злонамеренного автора.

Вы должны использовать только программное обеспечение с большим количеством хороших публичных обзоров. В качестве авторов, которым вы доверяете здесь, в Ask Ubuntu, таких как Серж, Джейкоб, Колин Кинг и т. Д. Другие уважаемые сайты, такие как Ask Ubuntu и их уважаемые участники, также должны рассматриваться как "не вредоносные".

Преимущество "уважаемых авторов" здесь, в Ask Ubuntu, заключается в том, что они ставят свою самооценку на "очки репутации". Если бы они намеренно написали код, который "украл" или "испортил" данные, они бы быстро потеряли свою репутацию. Действительно, авторы могут страдать от "гнева модов" и быть отстраненными от работы и / или лишить 10000 очков репутации.

Изменить 2 - Не следуйте всем инструкциям

Я более подробно изучил инструкции вашего bash-скрипта:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
    cd ~/42FileChecker &&
    bash ./42FileChecker.sh

"Безопасный" метод заключается в запуске только первой строки:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker

Это загружает сценарии, но не запускает их. Следующее использование nautilus (файловый менеджер) для проверки установленных каталогов и файлов. Очень быстро вы обнаружите, что есть коллекция сценариев bash, написанных группой студентов во Франции.

Целью скриптов является компиляция и тестирование программ на Си на предмет неправильных функций и утечек памяти.

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

Чтобы установить докер:

sudo apt-get install docker.io

Чтобы загрузить новый контейнер Ubuntu Bionic:

docker pull ubuntu:bionic

После этого войдите в контейнер

docker run -it ubuntu:bionic

и выполнить в нем хитрую операцию:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh

Попробуйте использовать режим отладки, запустив скрипт как:

$ bash -x scriptname

Дополнительная полезная информация Bash

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

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

Соответствующая информация для предоставления ответа, к сожалению, находится только в вашем комментарии:

Я изучаю C на курсе Ecole 42. Функции, которые я выполняю, должны пройти через эту проверку норм. Мне нужно установить 42FileChecker в Ubuntu, чтобы запустить эту проверку норм.

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

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

Запрет на маловероятную возможность действительно грубого эксплойта, содержащегося в этом скрипте, вход в систему под любым пользователем без полномочий root (который вы вряд ли выберете в Ubuntu иным способом) и избегание ввода sudo без всякой очевидной причины в значительной степени предотвращает 99% всех плохих вещей, которые могут произойти в любом случае. Например, форматирование жесткого диска, о котором вы беспокоитесь. Обычный пользователь просто не может этого сделать. Худшее, что может случиться, - это сценарий, удаляющий домашний каталог пользователя. Так что, не проблема, правда.