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

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

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

sudo snap install multipass --beta --classic

Вращать новую виртуальную машину:

multipass launch --name myvm

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

multipass shell myvm

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

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

Я не эксперт в этом, но я бы порекомендовал использовать strace и docker.

Итак, сначала создайте контейнер Docker, следуя инструкциям в этого ответа . Но дополнение в том, что strace скажет вам, какие системные вызовы сделаны. Или цитата:

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

Вы можете объединить эти команды в

docker exec -it ubuntu_container strace bash ./42FileChecker.sh

Вы можете использовать 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

Релевантная информация для предоставления ответа к несчастью только найдена в вашем комментарии:

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

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

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

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

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

$ bash -x scriptname

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

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

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

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

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

У вас есть 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, заключается в том, что они ставят свою самооценку на «очки репутации». Если бы они намеренно написали код, который «украл» или «испортил» данные, они бы быстро потеряли свою репутацию. Действительно, авторы могут страдать от "гнева модов" и быть отстраненными от работы и / или лишить 10 000 очков репутации.

Правка 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, написанных группой студентов во Франции.

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