Скрипт с suid-битом

http://stackoverflow.com/questions/18698976/suid-not-working-with-shell-script

Если кратко, то

Shell scripts can't be SUID. See http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html

Сделай через sudo NOPASSWD (http://unix.stackexchange.com/questions/18830/how-to-run-a-specific-program-a...), так работает

Скрипт на самом деле - просто текстовый файл, который скармливается интерпретатору указанному в первой строке. Соответственно, интерпретатору похрен на suid бит какого-то там текстового файла.

Так что пользуй sudo и не морочь себе голову

интерпретатору похрен на suid бит какого-то там текстового файла

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

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

Разумеется, как 2 пальца можно ковырнуть любой интерпретатор, чтоб он суид бит скрипта подхватывал

А некоторые и ковырять не надо. Так Перл, кажется, это умеет, например.

А некоторые и ковырять не надо. Так Перл, кажется, это умеет, например.

Не совсем. Перл попытается запустить suidperl если он есть. Это просто использование самого интерпретатора с выставленным suid битом. Даже не знаю, остался ли он до сих пор - древний костыль, использовать который крайне неразумно. Так можно любой интерпретатор суиднуть и пользовать какой-нибудь /bin/my_suid_sh вместо /bin/sh в скриптах. И это крайне дурацкая затея.

Забыл написал, условия задачи подразумевают, что sudo использовать нельзя.
Задача подразумевает, что нужно произвести какие-то действия с файловой системой с правами рута, но чтобы запустить мог обычный пользователь, и в процессе действия должны производиться фильтрация и запись вывода, фоновое выполнение - вобщем без скрипта не обойтись. Какие будут соображения?
Да, и если ядро игнорирует suid-бит для для запуска скриптов, то каким образом оно распознаёт, что это именно скрипт, ведь для ядра это просто /bin/bash?
И ещё, как же тогда реализовано, что пользователь запускает скрипт /usr/bin/startx, но в результате /usr/bin/Xorg запускается с правами рута?

Да, и если ядро игнорирует suid-бит для для запуска скриптов, то каким образом оно распознаёт, что это именно скрипт, ведь для ядра это просто /bin/bash?

Скрипт сам по себе не исполняется, поэтому ставить для него suid нет смысла. Ядро просто передаёт его bash'у. У которого suid нет, что характерно.

И ещё, как же тогда реализовано, что пользователь запускает скрипт /usr/bin/startx, но в результате /usr/bin/Xorg запускается с правами рута?

А ты посмотри права. У startx нет suid-бита, он у /usr/bin/Xorg.

А некоторые и ковырять не надо. Так Перл, кажется, это умеет, например.

Не совсем. Перл попытается запустить suidperl если он есть.

И что здесь «не совсем»?

использовать который крайне неразумно

Почему?

Понятно! То есть для решения задачи нужно вместо скрипта скомпилировать бинарник. Но это как-нибудь потом, а пока другой вопрос: вот я запускаю в рут-консоли grep -r 192.168 /etc &>findme.log &, мне выводится [1] 23067, а почему? Ведь выводиться ничего не должно, весь вывод в файл переправляется.

Он показывает id процесса, который ушёл в фон.

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

Теоретически, можно просто скопировать бинарник командного интерпретатора, выставить на него требуемые права и передавать скрипт аргументом.

мне выводится [1] 23067, а почему?

Потому что stdo и stderr висят на разных дескрипторах.

И что здесь «не совсем»?

Система вовсе не запускает интерпретатор с изменёнными привилегиями, как это было бы в случае суиднутого бинарника.

Почему?

Догадайся, чем чревато наличие в системе суиднутого шелла, например.

Система вовсе не запускает интерпретатор с изменёнными привилегиями, как это было бы в случае суиднутого бинарника.

А что же она делает? Там именно что двоичная исполняемость с suid-битом.

Догадайся, чем чревато наличие в системе суиднутого шелла, например.

Какая связь?

Сделай через sudo NOPASSWD (http://unix.stackexchange.com/questions/18830/how-to-run-a-specific-program-a...), так работает

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

А что же она делает?

Она как обычно запускает интерпретатор из-под юзверя который запустил скрипт и скармливает ему сам скрипт. Всё.

Там именно что двоичная исполняемость с suid-битом.

Это уже потом, когда интерпретатор обнаружит что на скрипте есть suid-бит, он запустит suidperl и скормит ему скрипт. Вот только тут уже будет запуск суиднутого бинарника.

В ядрёном модуле binfmt_script (который и запускает скрипты в системе, тащемта) вообще нет ничего про setuid. В этом и разница.

Какая связь?

Связь с чем?

ЗЫ: Кстати, как оказалось, эти все костыли уже давным-давно выкинули из перла. :)

Это уже потом, когда интерпретатор обнаружит что на скрипте есть suid-бит, он запустит suidperl и скормит ему скрипт. Вот только тут уже будет запуск суиднутого бинарника.

Так что же здесь не так? Вы что, знаете другой способ, каким «как два пальца можно ковырнуть любой интерпретатор, чтоб он суид-бит скрипта подхватывал»?

Так что же здесь не так? Вы что, знаете другой способ, каким «как два пальца можно ковырнуть любой интерпретатор, чтоб он суид-бит скрипта подхватывал»?

Элементарно же - интерпретатору ставится suid root:root, а там, где он открывает скормленный ему скрипт, привилегии дропаются либо до запустившего процесс (ruid), либо, если на файле стоит suid-бит, до привилегий владельца файла.

Спроектировал дырищу. Сработал предохранитель, и теперь ты пытаешься его закоротить.