Почему мои сценарии оболочки setuid root bash не работают?

Я создал этот простой скрипт, чтобы позволить пользователю удалять файлы, созданные веб-сервером, в его домашнем каталоге, не давая ему «su». Для обоих сценариев задано "chmod 4750".

Самое безумное, что они ДЕЙСТВИТЕЛЬНО работали, а теперь нет. Вот скрипты:

#!/bin/bash

# Ask for directory to delete
echo "Enter the file or directory you would like to delete, the assumed path is    /home/user"

read DIRECTORY

rm -rf /home/user/"$DIRECTORY"

echo "Deleting /home/user/$DIRECTORY ..."

exit 0

2:

#!/bin/bash

# Reset permissions
echo "Resetting the ownership of the contents of /home/user to user."

chown -R user /home/user

exit 0

Я сделаю их немного более продвинутыми и работающими для нескольких пользователей, но сейчас я не могу заставить работать даже простую версию. Конечно, это работает при запуске от имени root. Раньше он работал при запуске от имени пользователя «пользователь», но теперь это не так. Я получаю это:

user@dev:/home/user$ delete.sh
Enter the file or directory you would like to delete, the assumed path is /home/user/[your input]
test-dir
rm: cannot remove ‘/home/user/test-dir/test-file’: Permission denied
Deleting /home/user/test-dir ...

а также

chown: changing ownership of ‘/home/user/test-dir’: Operation not permitted

В чем может быть проблема?

-rwsr-x--- 1 root user 291 Nov  6 05:23 delete.sh
-rwsr-x--- 1 root user 177 Nov  6 05:45 perms.sh

bash permissions chmod chown setuid
person Bob    schedule 06.11.2015    source источник
comment
Проверьте, работает ли SUID, добавьте в скрипт: echo whoami выходной корень? .   -  person Noproblem    schedule 06.11.2015
comment
В качестве меры безопасности большинство систем не позволяют устанавливать идентификаторы сценариев оболочки. Хотя непонятно, почему раньше они работали.   -  person chepner    schedule 06.11.2015
comment
Странно то, что это работало ранее сегодня на той же системе. Я не знаю, что я изменил или что изменилось. Я попробую это.   -  person Bob    schedule 06.11.2015
comment
Вы угадали, но как это исправить и почему это работало раньше?   -  person Bob    schedule 06.11.2015
comment
Что мешает ввести ../../etc/passwd в DIRECTORY для сброса всех паролей (включая root)?   -  person 12431234123412341234123    schedule 11.03.2019

Ответы (1)


arrow_upward
6
arrow_downward

На https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts

Суть в том, что против него есть два основных аргумента:

  1. Состояние гонки между моментом, когда ядро ​​открывает файл, чтобы определить, какой интерпретатор следует выполнить, и моментом, когда интерпретатор открывает файл для чтения сценария.
  2. Сценарии оболочки, которые выполняют множество внешних программ без надлежащих проверок, могут быть обмануты выполнением неправильной программы (например, с использованием вредоносного пути PATH) или некорректным расширением переменных (например, наличием пробелов в значениях переменных), и, как правило, он имеет меньше контроля над тем, как хорошо, внешние программы, которые он выполняет, обрабатывают ввод.

Исторически в оригинальной оболочке Bourne была известная ошибка (по крайней мере, в 4.2BSD, где я видел это в действии), которая позволяла любому получить интерактивную корневую оболочку, создав символическую ссылку с именем -i на сценарий оболочки suid. Возможно, это первоначальный триггер для запрета.

РЕДАКТИРОВАТЬ: Чтобы ответить, как это исправить, настройте sudo, чтобы пользователи могли выполнять только эти сценарии от имени пользователя root, и, возможно, используйте трюк, как в https://stackoverflow.com/a/4598126/164137, чтобы найти исходное имя пользователя и принудительно выполнить операцию в своем собственном домашнем каталоге, вместо того, чтобы позволять им передавать любой произвольный ввод (т.е. в их текущем состоянии ничего в сценариях, которые вы включаете в свой вопрос, не позволяет user1 выполнять сценарии и передавать им каталог users2 или любой другой каталог, если на то пошло)

person Amos Shapira    schedule 08.11.2015