Как обеспечить работу звука?

Если у пользователя нет разрешения на чтение исполняемого скрипта, то попытка запустить его завершится неудачей , если у пользователя нет CAP_DAC_OVERRIDEвозможности (, например. она корень):

$ cat > yup; chmod 100 yup
#! /bin/sh
echo yup
^D
$./yup
/bin/sh: 0: Can't open./yup

Интерпретатор (при неудачном или успешном выполнении )всегда будет работать от имени текущего пользователя, игнорируя любые биты setuid или расширенные атрибуты setcap скрипта.

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

$ cat > interp; chmod 755 interp
#! /bin/sh
printf 'you said %s\n' "$1"
^D
$ cat > script; chmod 100 script
#!./interp
nothing to see here
^D
$./script
you said./script

Конечно, сам интерпретатор может быть двоичным файлом setuid илиcap_dac_override=ep-setcap (или передавать путь сценария в качестве аргумента такому двоичному файлу ), и в этом случае он будет работать с повышенными привилегиями и может игнорировать любые права доступа к файлам.

Нечитаемые сценарии setuid в Linux через binfmt _разное

В Linux вы можете обойти все ограничения на исполняемые скрипты (и разрушить вашу систему; -))с помощью модуля binfmt_misc:

Как root:

# echo ':interp-test:M::#!./interp::./interp:C' \
    > /proc/sys/fs/binfmt_misc/register

# cat > /tmp/script <<'EOT'; chmod 4001 /tmp/script # just exec + setuid
#!./interp
id -u
EOT

Как обычный пользователь:

$ echo 'int main(void){ dup2(getauxval(AT_EXECFD), 0); execl("/bin/sh", "sh", "-p", (void*)0); }' |
    cc -include sys/auxv.h -include unistd.h -x c - -o./interp
$ /tmp/script
0

Яппи!

Больше информации вDocumentation/admin-guide/binfmt-misc.rstв исходниках ядра.

Опция -pможет вызвать ошибку в некоторых оболочках (, где ее можно просто удалить ), но она необходима в более новых версиях dashи bash, чтобы предотвратить их . ] сброс привилегий , даже если они не запрашиваются.

Как правило, скрипты не могут выполняться без разрешения «r», даже если вы являетесь владельцем файла

$ ls -l tst
---x--x--x 1 sweh sweh 24 May  4 21:22 tst*

$./tst
/bin/bash:./tst: Permission denied

$ sudo cat tst
#!/bin/bash

echo hello

С вашим отредактированным вопросом.

Часть #!программы интерпретируется ядром как часть системного вызова exec(). Так что, чтобы зайти так далеко, сценарий не обязательно должен быть читабельным.

Фактически в моем примере происходит то, что ядро ​​преобразует мой вызов ./tstв вызов /bin/bash./tst.

Это преобразование объясняет, почему сценарии должны иметь rдоступ для обработки, а ядру достаточно xдля определения используемого интерпретатора.

Выполнение сценария происходит в два этапа. Сначала ядро ​​читает начало файла и видит, что оно начинается с #!, поэтому оно читает строку shebang и определяет, какой интерпретатор вызывать. Затем ядро ​​преобразует исходную командную строку в путь к интерпретатору, опцию (s )¹ в строке shebang, если она есть, путь к файлу и исходные опции. Затем он выполняет эту командную строку, в основном так, как если бы это была командная строка все время, но без какой-либо дальнейшей обработки.

До сих пор ядро ​​проверяло, есть ли у вызывающего объекта разрешение на выполнение файла сценария. Разрешение на чтение не вступило в игру. Ядро читает начало файла как часть его выполнения, поэтому это контролируется разрешением на выполнение, а не разрешением на чтение.

На втором этапе выполняется интерпретатор. Поскольку он видит имя файла сценария в своей командной строке, он, вероятно, попытается его открыть. Это тот момент, когда необходимо разрешение на чтение. Если у интерпретатора нет разрешения на чтение файла, его вызов openзавершится ошибкой, а затем, вероятно, интерпретатор напечатает сообщение об ошибке и сдастся. Я говорю «предположительно», потому что это то, что делает каждый здравомыслящий интерпретатор, но нет никаких технических обязательств, что все происходит именно так. Если вы используете программу, которая не является интерпретатором строки shebang, это не имеет никакого значения на первом этапе, но программа будет делать то же, что и на втором этапе. Например,«сценарий», начинающийся с #!/bin/echo, просто напечатает имя файла сценария и любой дополнительный аргумент командной строки, а затем завершится, и для этого сценарий должен быть только исполняемым.

¹ _{Многие ядра, включая Linux, допускают только одну опцию.}