Могут ли сценарии запускаться, даже если они не установлены как исполняемые?

Попробуйте Virtualbox, а не бесплатно, и интернет подключен через ваш хост Ubuntu, поэтому нет беспорядка. Я нашел это, на самом деле, лучшей виртуальной машиной, вы даже получаете 3D-ускорение для графики.

Альтернативно вы можете посмотреть на двойная загрузка, тогда вы можете иметь окна и Ubuntu на одном компьютере, и оба запускаются на полной скорости

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

19
задан 10 February 2011 в 22:27

40 ответов

Допустим, у вас есть файл myscript, содержащий следующее:

#!/bin/bash
echo "Hello, World!"

Если вы сделаете этот файл исполняемым и запустите его с помощью ./myscript, то ядро ​​увидит, что первые два байта #!, что означает, что это файл сценария. Затем ядро ​​будет использовать остальную часть строки в качестве интерпретатора и передать файл в качестве первого аргумента. Таким образом, он запускается:

/bin/bash myscript

, а bash читает файл и выполняет команды, которые он содержит.

Таким образом, для bash (или любого другого интерпретатора, который требуется вашему сценарию) для «выполнения», сценарий, он должен только читать файл.

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

16
ответ дан 25 May 2018 в 23:03
  • 1
    Спасибо за подробное объяснение. :) Если бы я понял это правильно, любой пользовательский доступ к bash просто нуждался в чтении доступа к скрипту для его запуска, потому что bash возьмет скрипт как входной файл и ему нужно будет только его прочитать. Я могу остановить это поведение, получив разрешение чтения для этого пользователя. Правильно? Поэтому, когда используется это исполняемое разрешение & amp; это важно? – Ashfame 11 February 2011 в 00:02
  • 2
    Да, если вы используете «bash myscript», то пользователю нужен только доступ на чтение для «myscript». (и, конечно, исполняемый файл для / bin / bash, если bash находится внутри пути). Однако, если вы делаете свой скрипт исполняемым, все немного отличается. Это правда, что с точки зрения ядра это будет «/ bin / bash myscript». снова, если первая строка - #! / bin / bash, но чтобы достичь этой точки, сначала вам нужно представить скрипт как исполняемый файл для пользователя или группы. Однако это верно, если для некоторого пользователя сценарий не является исполняемым, но читаемым, (и) он все еще может «запускать»; сценарий с "bash myscript" .... – LGB 11 February 2011 в 01:40
  • 3
    @LGB Так что это почти бесполезно. Хорошо, чтобы вырезать разрешение на чтение от пользователя для этого скрипта. Правильно? – Ashfame 11 February 2011 в 02:08
  • 4
    @Ashfame: Я бы сказал, полезный, а не бесполезный. Бит выполнения на обычных файлах не используется (и никогда не предназначался) для ограничения доступа. Похоже, вы ожидаете этого. Если у вас есть исполняемый файл, вы должны иметь разрешение на выполнение для его запуска. Однако, если у вас есть доступ к нему, вы всегда можете скопировать файл в свой собственный домашний каталог, и в этом случае копия будет принадлежать вам, поэтому вы можете добавить к ней разрешение на выполнение ... и запустить ее. Однако для каталогов это имеет немного другую цель. См. mywiki.wooledge.org/Permissions – geirha 11 February 2011 в 02:21
  • 5
    Что я должен использовать вместо / bin / bash, если я не знаю правильного интерпретатора? Есть ли команда, которая запускает скрипт в соответствии со строкой shebang? – Aivar 17 November 2016 в 12:51

Допустим, у вас есть файл myscript, содержащий следующее:

#!/bin/bash echo "Hello, World!"

Если вы сделаете этот файл исполняемым и запустите его с помощью ./myscript, то ядро ​​увидит, что первые два байта #!, что означает, что это файл сценария. Затем ядро ​​будет использовать остальную часть строки в качестве интерпретатора и передать файл в качестве первого аргумента. Таким образом, он запускается:

/bin/bash myscript

, а bash читает файл и выполняет команды, которые он содержит.

Таким образом, для bash (или любого другого интерпретатора, который требуется вашему сценарию) для «выполнения», сценарий, он должен только читать файл.

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

18
ответ дан 25 July 2018 в 22:30

Допустим, у вас есть файл myscript, содержащий следующее:

#!/bin/bash echo "Hello, World!"

Если вы сделаете этот файл исполняемым и запустите его с помощью ./myscript, то ядро ​​увидит, что первые два байта #!, что означает, что это файл сценария. Затем ядро ​​будет использовать остальную часть строки в качестве интерпретатора и передать файл в качестве первого аргумента. Таким образом, он запускается:

/bin/bash myscript

, а bash читает файл и выполняет команды, которые он содержит.

Таким образом, для bash (или любого другого интерпретатора, который требуется вашему сценарию) для «выполнения», сценарий, он должен только читать файл.

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

18
ответ дан 31 July 2018 в 10:38

Допустим, у вас есть файл myscript, содержащий следующее:

#!/bin/bash echo "Hello, World!"

Если вы сделаете этот файл исполняемым и запустите его с помощью ./myscript, то ядро ​​увидит, что первые два байта #!, что означает, что это файл сценария. Затем ядро ​​будет использовать остальную часть строки в качестве интерпретатора и передать файл в качестве первого аргумента. Таким образом, он запускается:

/bin/bash myscript

, а bash читает файл и выполняет команды, которые он содержит.

Таким образом, для bash (или любого другого интерпретатора, который требуется вашему сценарию) для «выполнения», сценарий, он должен только читать файл.

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

18
ответ дан 31 July 2018 в 11:41

Допустим, у вас есть файл myscript, содержащий следующее:

#!/bin/bash echo "Hello, World!"

Если вы сделаете этот файл исполняемым и запустите его с помощью ./myscript, то ядро ​​увидит, что первые два байта #!, что означает, что это файл сценария. Затем ядро ​​будет использовать остальную часть строки в качестве интерпретатора и передать файл в качестве первого аргумента. Таким образом, он запускается:

/bin/bash myscript

, а bash читает файл и выполняет команды, которые он содержит.

Таким образом, для bash (или любого другого интерпретатора, который требуется вашему сценарию) для «выполнения», сценарий, он должен только читать файл.

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

18
ответ дан 2 August 2018 в 03:56

Допустим, у вас есть файл myscript, содержащий следующее:

#!/bin/bash echo "Hello, World!"

Если вы сделаете этот файл исполняемым и запустите его с помощью ./myscript, то ядро ​​увидит, что первые два байта #!, что означает, что это файл сценария. Затем ядро ​​будет использовать остальную часть строки в качестве интерпретатора и передать файл в качестве первого аргумента. Таким образом, он запускается:

/bin/bash myscript

, а bash читает файл и выполняет команды, которые он содержит.

Таким образом, для bash (или любого другого интерпретатора, который требуется вашему сценарию) для «выполнения», сценарий, он должен только читать файл.

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

18
ответ дан 4 August 2018 в 20:00

Допустим, у вас есть файл myscript, содержащий следующее:

#!/bin/bash echo "Hello, World!"

Если вы сделаете этот файл исполняемым и запустите его с помощью ./myscript, то ядро ​​увидит, что первые два байта #!, что означает, что это файл сценария. Затем ядро ​​будет использовать остальную часть строки в качестве интерпретатора и передать файл в качестве первого аргумента. Таким образом, он запускается:

/bin/bash myscript

, а bash читает файл и выполняет команды, которые он содержит.

Таким образом, для bash (или любого другого интерпретатора, который требуется вашему сценарию) для «выполнения», сценарий, он должен только читать файл.

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

18
ответ дан 6 August 2018 в 04:01

Допустим, у вас есть файл myscript, содержащий следующее:

#!/bin/bash echo "Hello, World!"

Если вы сделаете этот файл исполняемым и запустите его с помощью ./myscript, то ядро ​​увидит, что первые два байта #!, что означает, что это файл сценария. Затем ядро ​​будет использовать остальную часть строки в качестве интерпретатора и передать файл в качестве первого аргумента. Таким образом, он запускается:

/bin/bash myscript

, а bash читает файл и выполняет команды, которые он содержит.

Таким образом, для bash (или любого другого интерпретатора, который требуется вашему сценарию) для «выполнения», сценарий, он должен только читать файл.

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

18
ответ дан 7 August 2018 в 22:00

Допустим, у вас есть файл myscript , содержащий следующее:

  #! / bin / bash echo "Hello, World!"   

Если вы делаете этот файл исполняемым и запускаете его с помощью ./ myscript , то ядро ​​увидит, что первые два байта - #! , что означает, что это файл сценария. Затем ядро ​​будет использовать остальную часть строки в качестве интерпретатора и передать файл в качестве первого аргумента. Таким образом, он запускается:

  / bin / bash myscript  

, а bash читает файл и выполняет команды, которые он содержит.

Таким образом, для bash (или любого другого интерпретатора, который требуется вашему скрипту) для «выполнения» сценария, он должен только читать файл.

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

18
ответ дан 10 August 2018 в 10:14

Допустим, у вас есть файл myscript , содержащий следующее:

  #! / bin / bash echo "Hello, World!"   

Если вы делаете этот файл исполняемым и запускаете его с помощью ./ myscript , то ядро ​​увидит, что первые два байта - #! , что означает, что это файл сценария. Затем ядро ​​будет использовать остальную часть строки в качестве интерпретатора и передать файл в качестве первого аргумента. Таким образом, он запускается:

  / bin / bash myscript  

, а bash читает файл и выполняет команды, которые он содержит.

Таким образом, для bash (или любого другого интерпретатора, который требуется вашему скрипту) для «выполнения» сценария, он должен только читать файл.

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

18
ответ дан 13 August 2018 в 16:37
  • 1
    Спасибо за подробное объяснение. :) Если бы я понял это правильно, любой пользовательский доступ к bash просто нуждался в чтении доступа к скрипту для его запуска, потому что bash возьмет скрипт как входной файл и ему нужно будет только его прочитать. Я могу остановить это поведение, получив разрешение чтения для этого пользователя. Правильно? Поэтому, когда используется это исполняемое разрешение & amp; это важно? – Ashfame 11 February 2011 в 00:02
  • 2
    Да, если вы используете «bash myscript», то пользователю нужен только доступ на чтение для «myscript». (и, конечно, исполняемый файл для / bin / bash, если bash находится внутри пути). Однако, если вы делаете свой скрипт исполняемым, все немного отличается. Это правда, что с точки зрения ядра это будет «/ bin / bash myscript». снова, если первая строка - #! / bin / bash, но чтобы достичь этой точки, сначала вам нужно представить скрипт как исполняемый файл для пользователя или группы. Однако это верно, если для некоторого пользователя сценарий не является исполняемым, но читаемым, (и) он все еще может «запускать»; сценарий с "bash myscript" .... – LGB 11 February 2011 в 01:40
  • 3
    @LGB Так что это почти бесполезно. Хорошо, чтобы вырезать разрешение на чтение от пользователя для этого скрипта. Правильно? – Ashfame 11 February 2011 в 02:08
  • 4
    @Ashfame: Я бы сказал, полезный, а не бесполезный. Бит выполнения на обычных файлах не используется (и никогда не предназначался) для ограничения доступа. Похоже, вы ожидаете этого. Если у вас есть исполняемый файл, вы должны иметь разрешение на выполнение для его запуска. Однако, если у вас есть доступ к нему, вы всегда можете скопировать файл в свой собственный домашний каталог, и в этом случае копия будет принадлежать вам, поэтому вы можете добавить к ней разрешение на выполнение ... и запустить ее. Однако для каталогов это имеет немного другую цель. См. [D0] mywiki.wooledge.org/Permissions – geirha 11 February 2011 в 02:21
  • 5
    Что я должен использовать вместо / bin / bash, если я не знаю правильного интерпретатора? Есть ли команда, которая запускает скрипт в соответствии со строкой shebang? – Aivar 17 November 2016 в 12:51

Убедитесь, что вы не сбиваете с толку «выполнение сценария оболочки» с помощью «запуска скрипта оболочки с помощью sh».

На file.sh не будут влиять права доступа к файлам:

[ f1]

Вы выполняете sh (который разрешает программу /bin/sh), которая читает file.sh и выполняет его код.

Разрешения для файлов будут иметь эффект, если вы действительно выполняете скрипт self:

./file.sh

Обратите внимание, что разрешения файлов не поддерживаются файловыми системами, отличными от Linux, например FAT. Таким образом, даже если вы запустите chmod -x file.sh, у файла все еще будут свои прежние разрешения.

Выполнение разрешения выполняется файловой системой. Но программы также могут «выполнять» код, читая содержимое файла, которое обходит разрешения файловой системы «execute».

12
ответ дан 25 May 2018 в 23:03
  • 1
    Я понимаю вашу мысль. Но тогда это для группы или мира или для обоих? – Ashfame 10 February 2011 в 23:04
  • 2
    @Ashfame Если вы установите разрешение на выполнение, сценарий может запускаться непосредственно пользователями, у которых есть это разрешение, независимо от того, есть ли у них это на основе группы, мира или владельца. Но даже люди без разрешения на выполнение могут выполнить его, вызвав другую программу (например, bash), чтобы выполнить выполнение - чтобы заблокировать это, вы также должны были бы удалить свое разрешение read. – j-g-faustus 10 February 2011 в 23:37
  • 3
    If you set the executable permission, the script can be run directly by users who have that permission - whether they have it on a group, world or owner basis Но как разрешение предоставляется другим пользователям, проверяя разрешение на выполнение? И у меня есть второй момент. Вы имеете в виду отнять их разрешение на чтение скрипта, чтобы они не могли обработать его через bash. Правильно? – Ashfame 10 February 2011 в 23:58
  • 4
    @Ashfame На точке разрешения чтения да. О том, как вы могли бы назвать что-то вроде sudo chmod g+x myfile.sh в терминале, чтобы добавить разрешения на выполнение для группы файлов. См. Учебник по разрешению файлов . Чтобы управлять разрешениями для нескольких пользователей одновременно, вы должны использовать группы, например, Управление группами . – j-g-faustus 11 February 2011 в 01:43
  • 5
    что я имел в виду, когда мы добавляем исполняемые разрешения в GUI, то это для кого? владелец / группа / мир? – Ashfame 11 February 2011 в 01:57

Не думай об этом так. Могу ли я выполнить этот файл? Подумайте об этом так: Кто может выполнить этот файл?

Если компьютер принадлежит вам, и файл принадлежит вам, я уверен, что вы можете его выполнить. Возможно, вам захочется взглянуть дальше на команды, такие как chmod и chown, и права доступа к файлам.

Надеюсь, что это поможет.

1
ответ дан 25 May 2018 в 23:03
  • 1
    Да, я знаю о них. Это означает, что я (владелец) всегда могу его выполнить. Правильно? Затем установить файл как исполняемый файл для группы или мира или обоих? – Ashfame 10 February 2011 в 23:05

Сценарий exec ядра Linux не работает с EACCES, если файл не является исполняемым

Пока вы можете делать sh myprog.sh, попытка запустить программу как ./myprog.sh не может работать, так как когда вы это делаете:

Bash использует системный вызов exec на ./myprog.sh, shebangs интерпретируются непосредственно системным вызовом exec ядра Linux, как описано в: https://stackoverflow.com / questions / 2429511 / why-do-people-write-the-usr-bin-env-python-shebang-on-the-first-line-of-a-pyt / 40938801 # 40938801 ядро ​​Linux отказывается выполнять файлы без исполняемое разрешение

Это можно проверить с помощью main.c:

#define _XOPEN_SOURCE 700
#include <errno.h>
#include <stdio.h>
#include <unistd.h>

int main(void) {
    char *argv[] = {"myprog", NULL};
    char *envp[] = {NULL};
    int ret;
    ret = execve("myprog.sh", argv, envp);
    perror("execve");
    printf("%d\n", errno);
    printf("%d\n", EACCES);
}

и myprog.sh:

#!/bin/sh
echo worked

Если myprog.sh не является исполняемым , main терпит неудачу:

execve: Permission denied
13
13

Протестировано в Ubuntu 17.10, gcc -std=c99.

POSIX 7 упоминает, что при:

Функции exec, за исключением fexecve (), не будет выполнено, если: [EACCES] Разрешение поиска отклонено для каталога, указанного в префиксе пути нового файла образа процесса, или новый файл образа процесса отклоняет разрешение на выполнение.

Дальнейшее обоснование можно найти по адресу: https://security.stackexchange.com/questions/66550/unix-execute-permission-can-be-easily-bypass-is-it-superfluous-or- Что-кнопки

0
ответ дан 25 May 2018 в 23:03

Сценарий exec ядра Linux не работает с EACCES, если файл не является исполняемым

Пока вы можете делать sh myprog.sh, попытка запустить программу как ./myprog.sh не может работать, так как когда вы это делаете:

Bash использует системный вызов exec на ./myprog.sh, shebangs интерпретируются непосредственно системным вызовом exec ядра Linux, как описано в: https://stackoverflow.com / questions / 2429511 / why-do-people-write-the-usr-bin-env-python-shebang-on-the-first-line-of-a-pyt / 40938801 # 40938801 ядро ​​Linux отказывается выполнять файлы без исполняемое разрешение

Это можно проверить с помощью main.c:

#define _XOPEN_SOURCE 700 #include <errno.h> #include <stdio.h> #include <unistd.h> int main(void) { char *argv[] = {"myprog", NULL}; char *envp[] = {NULL}; int ret; ret = execve("myprog.sh", argv, envp); perror("execve"); printf("%d\n", errno); printf("%d\n", EACCES); }

и myprog.sh:

#!/bin/sh echo worked

Если myprog.sh не является исполняемым , main терпит неудачу:

execve: Permission denied 13 13

Протестировано в Ubuntu 17.10, gcc -std=c99.

POSIX 7 упоминает, что при:

Функции exec, за исключением fexecve (), не будет выполнено, если: [EACCES] Разрешение поиска отклонено для каталога, указанного в префиксе пути нового файла образа процесса, или новый файл образа процесса отклоняет разрешение на выполнение.

Дальнейшее обоснование можно найти по адресу: https://security.stackexchange.com/questions/66550/unix-execute-permission-can-be-easily-bypass-is-it-superfluous-or- Что-кнопки

0
ответ дан 25 July 2018 в 22:30

Убедитесь, что вы не сбиваете с толку «выполнение сценария оболочки» с помощью «запуска скрипта оболочки с помощью sh».

На file.sh не будут влиять права доступа к файлам:

sh file.sh

Вы выполняете sh (который разрешает программу /bin/sh), которая читает file.sh и выполняет его код.

Разрешения для файлов будут иметь эффект, если вы действительно выполняете скрипт self:

./file.sh

Обратите внимание, что разрешения файлов не поддерживаются файловыми системами, отличными от Linux, например FAT. Таким образом, даже если вы запустите chmod -x file.sh, у файла все еще будут свои прежние разрешения.

Выполнение разрешения выполняется файловой системой. Но программы также могут «выполнять» код, читая содержимое файла, которое обходит разрешения файловой системы «execute».

13
ответ дан 25 July 2018 в 22:30
  • 1
    Я понимаю вашу мысль. Но тогда это для группы или мира или для обоих? – Ashfame 10 February 2011 в 23:04
  • 2
    @Ashfame Если вы установите разрешение на выполнение, сценарий может запускаться непосредственно пользователями, у которых есть это разрешение, независимо от того, есть ли у них это на основе группы, мира или владельца. Но даже люди без разрешения на выполнение могут выполнить его, вызвав другую программу (например, bash), чтобы выполнить выполнение - чтобы заблокировать это, вы также должны были бы удалить свое разрешение read. – j-g-faustus 10 February 2011 в 23:37
  • 3
    If you set the executable permission, the script can be run directly by users who have that permission - whether they have it on a group, world or owner basis Но как разрешение предоставляется другим пользователям, проверяя разрешение на выполнение? И у меня есть второй момент. Вы имеете в виду отнять их разрешение на чтение скрипта, чтобы они не могли обработать его через bash. Правильно? – Ashfame 10 February 2011 в 23:58
  • 4
    @Ashfame На точке разрешения чтения да. О том, как вы могли бы назвать что-то вроде sudo chmod g+x myfile.sh в терминале, чтобы добавить разрешения на выполнение для группы файлов. См. [D0] Учебник по разрешению файлов . Чтобы управлять разрешениями для нескольких пользователей одновременно, вы должны использовать группы, например, Управление группами . – j-g-faustus 11 February 2011 в 01:43
  • 5
    что я имел в виду, когда мы добавляем исполняемые разрешения в GUI, то это для кого? владелец / группа / мир? – Ashfame 11 February 2011 в 01:57

Не думай об этом так. Могу ли я выполнить этот файл? Подумайте об этом так: Кто может выполнить этот файл?

Если компьютер принадлежит вам, и файл принадлежит вам, я уверен, что вы можете его выполнить. Возможно, вам захочется взглянуть дальше на команды, такие как chmod и chown, и права доступа к файлам.

Надеюсь, что это поможет.

1
ответ дан 25 July 2018 в 22:30
  • 1
    Да, я знаю о них. Это означает, что я (владелец) всегда могу его выполнить. Правильно? Затем установить файл как исполняемый файл для группы или мира или обоих? – Ashfame 10 February 2011 в 23:05

Сценарий exec ядра Linux не работает с EACCES, если файл не является исполняемым

Пока вы можете делать sh myprog.sh, попытка запустить программу как ./myprog.sh не может работать, так как когда вы это делаете:

Bash использует системный вызов exec на ./myprog.sh, shebangs интерпретируются непосредственно системным вызовом exec ядра Linux, как описано в: https://stackoverflow.com / questions / 2429511 / why-do-people-write-the-usr-bin-env-python-shebang-on-the-first-line-of-a-pyt / 40938801 # 40938801 ядро ​​Linux отказывается выполнять файлы без исполняемое разрешение

Это можно проверить с помощью main.c:

#define _XOPEN_SOURCE 700 #include <errno.h> #include <stdio.h> #include <unistd.h> int main(void) { char *argv[] = {"myprog", NULL}; char *envp[] = {NULL}; int ret; ret = execve("myprog.sh", argv, envp); perror("execve"); printf("%d\n", errno); printf("%d\n", EACCES); }

и myprog.sh:

#!/bin/sh echo worked

Если myprog.sh не является исполняемым , main терпит неудачу:

execve: Permission denied 13 13

Протестировано в Ubuntu 17.10, gcc -std=c99.

POSIX 7 упоминает, что при:

Функции exec, за исключением fexecve (), не будет выполнено, если: [EACCES] Разрешение поиска отклонено для каталога, указанного в префиксе пути нового файла образа процесса, или новый файл образа процесса отклоняет разрешение на выполнение.

Дальнейшее обоснование можно найти по адресу: https://security.stackexchange.com/questions/66550/unix-execute-permission-can-be-easily-bypass-is-it-superfluous-or- Что-кнопки

0
ответ дан 31 July 2018 в 10:38

Убедитесь, что вы не сбиваете с толку «выполнение сценария оболочки» с помощью «запуска скрипта оболочки с помощью sh».

На file.sh не будут влиять права доступа к файлам:

sh file.sh

Вы выполняете sh (который разрешает программу /bin/sh), которая читает file.sh и выполняет его код.

Разрешения для файлов будут иметь эффект, если вы действительно выполняете скрипт self:

./file.sh

Обратите внимание, что разрешения файлов не поддерживаются файловыми системами, отличными от Linux, например FAT. Таким образом, даже если вы запустите chmod -x file.sh, у файла все еще будут свои прежние разрешения.

Выполнение разрешения выполняется файловой системой. Но программы также могут «выполнять» код, читая содержимое файла, которое обходит разрешения файловой системы «execute».

13
ответ дан 31 July 2018 в 10:38
  • 1
    Я понимаю вашу мысль. Но тогда это для группы или мира или для обоих? – Ashfame 10 February 2011 в 23:04
  • 2
    @Ashfame Если вы установите разрешение на выполнение, сценарий может запускаться непосредственно пользователями, у которых есть это разрешение, независимо от того, есть ли у них это на основе группы, мира или владельца. Но даже люди без разрешения на выполнение могут выполнить его, вызвав другую программу (например, bash), чтобы выполнить выполнение - чтобы заблокировать это, вы также должны были бы удалить свое разрешение read. – j-g-faustus 10 February 2011 в 23:37
  • 3
    If you set the executable permission, the script can be run directly by users who have that permission - whether they have it on a group, world or owner basis Но как разрешение предоставляется другим пользователям, проверяя разрешение на выполнение? И у меня есть второй момент. Вы имеете в виду отнять их разрешение на чтение скрипта, чтобы они не могли обработать его через bash. Правильно? – Ashfame 10 February 2011 в 23:58
  • 4
    @Ashfame На точке разрешения чтения да. О том, как вы могли бы назвать что-то вроде sudo chmod g+x myfile.sh в терминале, чтобы добавить разрешения на выполнение для группы файлов. См. [D0] Учебник по разрешению файлов . Чтобы управлять разрешениями для нескольких пользователей одновременно, вы должны использовать группы, например, Управление группами . – j-g-faustus 11 February 2011 в 01:43
  • 5
    что я имел в виду, когда мы добавляем исполняемые разрешения в GUI, то это для кого? владелец / группа / мир? – Ashfame 11 February 2011 в 01:57

Не думай об этом так. Могу ли я выполнить этот файл? Подумайте об этом так: Кто может выполнить этот файл?

Если компьютер принадлежит вам, и файл принадлежит вам, я уверен, что вы можете его выполнить. Возможно, вам захочется взглянуть дальше на команды, такие как chmod и chown, и права доступа к файлам.

Надеюсь, что это поможет.

1
ответ дан 31 July 2018 в 10:38
  • 1
    Да, я знаю о них. Это означает, что я (владелец) всегда могу его выполнить. Правильно? Затем установить файл как исполняемый файл для группы или мира или обоих? – Ashfame 10 February 2011 в 23:05

Сценарий exec ядра Linux не работает с EACCES, если файл не является исполняемым

Пока вы можете делать sh myprog.sh, попытка запустить программу как ./myprog.sh не может работать, так как когда вы это делаете:

Bash использует системный вызов exec на ./myprog.sh, shebangs интерпретируются непосредственно системным вызовом exec ядра Linux, как описано в: https://stackoverflow.com / questions / 2429511 / why-do-people-write-the-usr-bin-env-python-shebang-on-the-first-line-of-a-pyt / 40938801 # 40938801 ядро ​​Linux отказывается выполнять файлы без исполняемое разрешение

Это можно проверить с помощью main.c:

#define _XOPEN_SOURCE 700 #include <errno.h> #include <stdio.h> #include <unistd.h> int main(void) { char *argv[] = {"myprog", NULL}; char *envp[] = {NULL}; int ret; ret = execve("myprog.sh", argv, envp); perror("execve"); printf("%d\n", errno); printf("%d\n", EACCES); }

и myprog.sh:

#!/bin/sh echo worked

Если myprog.sh не является исполняемым , main терпит неудачу:

execve: Permission denied 13 13

Протестировано в Ubuntu 17.10, gcc -std=c99.

POSIX 7 упоминает, что при:

Функции exec, за исключением fexecve (), не будет выполнено, если: [EACCES] Разрешение поиска отклонено для каталога, указанного в префиксе пути нового файла образа процесса, или новый файл образа процесса отклоняет разрешение на выполнение.

Дальнейшее обоснование можно найти по адресу: https://security.stackexchange.com/questions/66550/unix-execute-permission-can-be-easily-bypass-is-it-superfluous-or- Что-кнопки

0
ответ дан 31 July 2018 в 11:41

Убедитесь, что вы не сбиваете с толку «выполнение сценария оболочки» с помощью «запуска скрипта оболочки с помощью sh».

На file.sh не будут влиять права доступа к файлам:

sh file.sh

Вы выполняете sh (который разрешает программу /bin/sh), которая читает file.sh и выполняет его код.

Разрешения для файлов будут иметь эффект, если вы действительно выполняете скрипт self:

./file.sh

Обратите внимание, что разрешения файлов не поддерживаются файловыми системами, отличными от Linux, например FAT. Таким образом, даже если вы запустите chmod -x file.sh, у файла все еще будут свои прежние разрешения.

Выполнение разрешения выполняется файловой системой. Но программы также могут «выполнять» код, читая содержимое файла, которое обходит разрешения файловой системы «execute».

13
ответ дан 31 July 2018 в 11:41
  • 1
    Я понимаю вашу мысль. Но тогда это для группы или мира или для обоих? – Ashfame 10 February 2011 в 23:04
  • 2
    @Ashfame Если вы установите разрешение на выполнение, сценарий может запускаться непосредственно пользователями, у которых есть это разрешение, независимо от того, есть ли у них это на основе группы, мира или владельца. Но даже люди без разрешения на выполнение могут выполнить его, вызвав другую программу (например, bash), чтобы выполнить выполнение - чтобы заблокировать это, вы также должны были бы удалить свое разрешение read. – j-g-faustus 10 February 2011 в 23:37
  • 3
    If you set the executable permission, the script can be run directly by users who have that permission - whether they have it on a group, world or owner basis Но как разрешение предоставляется другим пользователям, проверяя разрешение на выполнение? И у меня есть второй момент. Вы имеете в виду отнять их разрешение на чтение скрипта, чтобы они не могли обработать его через bash. Правильно? – Ashfame 10 February 2011 в 23:58
  • 4
    @Ashfame На точке разрешения чтения да. О том, как вы могли бы назвать что-то вроде sudo chmod g+x myfile.sh в терминале, чтобы добавить разрешения на выполнение для группы файлов. См. [D0] Учебник по разрешению файлов . Чтобы управлять разрешениями для нескольких пользователей одновременно, вы должны использовать группы, например, Управление группами . – j-g-faustus 11 February 2011 в 01:43
  • 5
    что я имел в виду, когда мы добавляем исполняемые разрешения в GUI, то это для кого? владелец / группа / мир? – Ashfame 11 February 2011 в 01:57

Не думай об этом так. Могу ли я выполнить этот файл? Подумайте об этом так: Кто может выполнить этот файл?

Если компьютер принадлежит вам, и файл принадлежит вам, я уверен, что вы можете его выполнить. Возможно, вам захочется взглянуть дальше на команды, такие как chmod и chown, и права доступа к файлам.

Надеюсь, что это поможет.

1
ответ дан 31 July 2018 в 11:41
  • 1
    Да, я знаю о них. Это означает, что я (владелец) всегда могу его выполнить. Правильно? Затем установить файл как исполняемый файл для группы или мира или обоих? – Ashfame 10 February 2011 в 23:05

Сценарий exec ядра Linux не работает с EACCES, если файл не является исполняемым

Пока вы можете делать sh myprog.sh, попытка запустить программу как ./myprog.sh не может работать, так как когда вы это делаете:

Bash использует системный вызов exec на ./myprog.sh, shebangs интерпретируются непосредственно системным вызовом exec ядра Linux, как описано в: https://stackoverflow.com / questions / 2429511 / why-do-people-write-the-usr-bin-env-python-shebang-on-the-first-line-of-a-pyt / 40938801 # 40938801 ядро ​​Linux отказывается выполнять файлы без исполняемое разрешение

Это можно проверить с помощью main.c:

#define _XOPEN_SOURCE 700 #include <errno.h> #include <stdio.h> #include <unistd.h> int main(void) { char *argv[] = {"myprog", NULL}; char *envp[] = {NULL}; int ret; ret = execve("myprog.sh", argv, envp); perror("execve"); printf("%d\n", errno); printf("%d\n", EACCES); }

и myprog.sh:

#!/bin/sh echo worked

Если myprog.sh не является исполняемым , main терпит неудачу:

execve: Permission denied 13 13

Протестировано в Ubuntu 17.10, gcc -std=c99.

POSIX 7 упоминает, что при:

Функции exec, за исключением fexecve (), не будет выполнено, если: [EACCES] Разрешение поиска отклонено для каталога, указанного в префиксе пути нового файла образа процесса, или новый файл образа процесса отклоняет разрешение на выполнение.

Дальнейшее обоснование можно найти по адресу: https://security.stackexchange.com/questions/66550/unix-execute-permission-can-be-easily-bypass-is-it-superfluous-or- Что-кнопки

0
ответ дан 2 August 2018 в 03:56

Убедитесь, что вы не сбиваете с толку «выполнение сценария оболочки» с помощью «запуска скрипта оболочки с помощью sh».

На file.sh не будут влиять права доступа к файлам:

sh file.sh

Вы выполняете sh (который разрешает программу /bin/sh), которая читает file.sh и выполняет его код.

Разрешения для файлов будут иметь эффект, если вы действительно выполняете скрипт self:

./file.sh

Обратите внимание, что разрешения файлов не поддерживаются файловыми системами, отличными от Linux, например FAT. Таким образом, даже если вы запустите chmod -x file.sh, у файла все еще будут свои прежние разрешения.

Выполнение разрешения выполняется файловой системой. Но программы также могут «выполнять» код, читая содержимое файла, которое обходит разрешения файловой системы «execute».

13
ответ дан 2 August 2018 в 03:56
  • 1
    Я понимаю вашу мысль. Но тогда это для группы или мира или для обоих? – Ashfame 10 February 2011 в 23:04
  • 2
    @Ashfame Если вы установите разрешение на выполнение, сценарий может запускаться непосредственно пользователями, у которых есть это разрешение, независимо от того, есть ли у них это на основе группы, мира или владельца. Но даже люди без разрешения на выполнение могут выполнить его, вызвав другую программу (например, bash), чтобы выполнить выполнение - чтобы заблокировать это, вы также должны были бы удалить свое разрешение read. – j-g-faustus 10 February 2011 в 23:37
  • 3
    If you set the executable permission, the script can be run directly by users who have that permission - whether they have it on a group, world or owner basis Но как разрешение предоставляется другим пользователям, проверяя разрешение на выполнение? И у меня есть второй момент. Вы имеете в виду отнять их разрешение на чтение скрипта, чтобы они не могли обработать его через bash. Правильно? – Ashfame 10 February 2011 в 23:58
  • 4
    @Ashfame На точке разрешения чтения да. О том, как вы могли бы назвать что-то вроде sudo chmod g+x myfile.sh в терминале, чтобы добавить разрешения на выполнение для группы файлов. См. [D0] Учебник по разрешению файлов . Чтобы управлять разрешениями для нескольких пользователей одновременно, вы должны использовать группы, например, Управление группами . – j-g-faustus 11 February 2011 в 01:43
  • 5
    что я имел в виду, когда мы добавляем исполняемые разрешения в GUI, то это для кого? владелец / группа / мир? – Ashfame 11 February 2011 в 01:57

Не думай об этом так. Могу ли я выполнить этот файл? Подумайте об этом так: Кто может выполнить этот файл?

Если компьютер принадлежит вам, и файл принадлежит вам, я уверен, что вы можете его выполнить. Возможно, вам захочется взглянуть дальше на команды, такие как chmod и chown, и права доступа к файлам.

Надеюсь, что это поможет.

1
ответ дан 2 August 2018 в 03:56
  • 1
    Да, я знаю о них. Это означает, что я (владелец) всегда могу его выполнить. Правильно? Затем установить файл как исполняемый файл для группы или мира или обоих? – Ashfame 10 February 2011 в 23:05

Сценарий exec ядра Linux не работает с EACCES, если файл не является исполняемым

Пока вы можете делать sh myprog.sh, попытка запустить программу как ./myprog.sh не может работать, так как когда вы это делаете:

Bash использует системный вызов exec на ./myprog.sh, shebangs интерпретируются непосредственно системным вызовом exec ядра Linux, как описано в: https://stackoverflow.com / questions / 2429511 / why-do-people-write-the-usr-bin-env-python-shebang-on-the-first-line-of-a-pyt / 40938801 # 40938801 ядро ​​Linux отказывается выполнять файлы без исполняемое разрешение

Это можно проверить с помощью main.c:

#define _XOPEN_SOURCE 700 #include <errno.h> #include <stdio.h> #include <unistd.h> int main(void) { char *argv[] = {"myprog", NULL}; char *envp[] = {NULL}; int ret; ret = execve("myprog.sh", argv, envp); perror("execve"); printf("%d\n", errno); printf("%d\n", EACCES); }

и myprog.sh:

#!/bin/sh echo worked

Если myprog.sh не является исполняемым , main терпит неудачу:

execve: Permission denied 13 13

Протестировано в Ubuntu 17.10, gcc -std=c99.

POSIX 7 упоминает, что при:

Функции exec, за исключением fexecve (), не будет выполнено, если: [EACCES] Разрешение поиска отклонено для каталога, указанного в префиксе пути нового файла образа процесса, или новый файл образа процесса отклоняет разрешение на выполнение.

Дальнейшее обоснование можно найти по адресу: https://security.stackexchange.com/questions/66550/unix-execute-permission-can-be-easily-bypass-is-it-superfluous-or- Что-кнопки

0
ответ дан 4 August 2018 в 20:00

Убедитесь, что вы не сбиваете с толку «выполнение сценария оболочки» с помощью «запуска скрипта оболочки с помощью sh».

На file.sh не будут влиять права доступа к файлам:

sh file.sh

Вы выполняете sh (который разрешает программу /bin/sh), которая читает file.sh и выполняет его код.

Разрешения для файлов будут иметь эффект, если вы действительно выполняете скрипт self:

./file.sh

Обратите внимание, что разрешения файлов не поддерживаются файловыми системами, отличными от Linux, например FAT. Таким образом, даже если вы запустите chmod -x file.sh, у файла все еще будут свои прежние разрешения.

Выполнение разрешения выполняется файловой системой. Но программы также могут «выполнять» код, читая содержимое файла, которое обходит разрешения файловой системы «execute».

13
ответ дан 4 August 2018 в 20:00
  • 1
    Я понимаю вашу мысль. Но тогда это для группы или мира или для обоих? – Ashfame 10 February 2011 в 23:04
  • 2
    @Ashfame Если вы установите разрешение на выполнение, сценарий может запускаться непосредственно пользователями, у которых есть это разрешение, независимо от того, есть ли у них это на основе группы, мира или владельца. Но даже люди без разрешения на выполнение могут выполнить его, вызвав другую программу (например, bash), чтобы выполнить выполнение - чтобы заблокировать это, вы также должны были бы удалить свое разрешение read. – j-g-faustus 10 February 2011 в 23:37
  • 3
    If you set the executable permission, the script can be run directly by users who have that permission - whether they have it on a group, world or owner basis Но как разрешение предоставляется другим пользователям, проверяя разрешение на выполнение? И у меня есть второй момент. Вы имеете в виду отнять их разрешение на чтение скрипта, чтобы они не могли обработать его через bash. Правильно? – Ashfame 10 February 2011 в 23:58
  • 4
    @Ashfame На точке разрешения чтения да. О том, как вы могли бы назвать что-то вроде sudo chmod g+x myfile.sh в терминале, чтобы добавить разрешения на выполнение для группы файлов. См. [D0] Учебник по разрешению файлов . Чтобы управлять разрешениями для нескольких пользователей одновременно, вы должны использовать группы, например, Управление группами . – j-g-faustus 11 February 2011 в 01:43
  • 5
    что я имел в виду, когда мы добавляем исполняемые разрешения в GUI, то это для кого? владелец / группа / мир? – Ashfame 11 February 2011 в 01:57

Не думай об этом так. Могу ли я выполнить этот файл? Подумайте об этом так: Кто может выполнить этот файл?

Если компьютер принадлежит вам, и файл принадлежит вам, я уверен, что вы можете его выполнить. Возможно, вам захочется взглянуть дальше на команды, такие как chmod и chown, и права доступа к файлам.

Надеюсь, что это поможет.

1
ответ дан 4 August 2018 в 20:00
  • 1
    Да, я знаю о них. Это означает, что я (владелец) всегда могу его выполнить. Правильно? Затем установить файл как исполняемый файл для группы или мира или обоих? – Ashfame 10 February 2011 в 23:05

Сценарий exec ядра Linux не работает с EACCES, если файл не является исполняемым

Пока вы можете делать sh myprog.sh, попытка запустить программу как ./myprog.sh не может работать, так как когда вы это делаете:

Bash использует системный вызов exec на ./myprog.sh, shebangs интерпретируются непосредственно системным вызовом exec ядра Linux, как описано в: https://stackoverflow.com / questions / 2429511 / why-do-people-write-the-usr-bin-env-python-shebang-on-the-first-line-of-a-pyt / 40938801 # 40938801 ядро ​​Linux отказывается выполнять файлы без исполняемое разрешение

Это можно проверить с помощью main.c:

#define _XOPEN_SOURCE 700 #include <errno.h> #include <stdio.h> #include <unistd.h> int main(void) { char *argv[] = {"myprog", NULL}; char *envp[] = {NULL}; int ret; ret = execve("myprog.sh", argv, envp); perror("execve"); printf("%d\n", errno); printf("%d\n", EACCES); }

и myprog.sh:

#!/bin/sh echo worked

Если myprog.sh не является исполняемым , main терпит неудачу:

execve: Permission denied 13 13

Протестировано в Ubuntu 17.10, gcc -std=c99.

POSIX 7 упоминает, что при:

Функции exec, за исключением fexecve (), не будет выполнено, если: [EACCES] Разрешение поиска отклонено для каталога, указанного в префиксе пути нового файла образа процесса, или новый файл образа процесса отклоняет разрешение на выполнение.

Дальнейшее обоснование можно найти по адресу: https://security.stackexchange.com/questions/66550/unix-execute-permission-can-be-easily-bypass-is-it-superfluous-or- Что-кнопки

0
ответ дан 6 August 2018 в 04:01

Убедитесь, что вы не сбиваете с толку «выполнение сценария оболочки» с помощью «запуска скрипта оболочки с помощью sh».

На file.sh не будут влиять права доступа к файлам:

sh file.sh

Вы выполняете sh (который разрешает программу /bin/sh), которая читает file.sh и выполняет его код.

Разрешения для файлов будут иметь эффект, если вы действительно выполняете скрипт self:

./file.sh

Обратите внимание, что разрешения файлов не поддерживаются файловыми системами, отличными от Linux, например FAT. Таким образом, даже если вы запустите chmod -x file.sh, у файла все еще будут свои прежние разрешения.

Выполнение разрешения выполняется файловой системой. Но программы также могут «выполнять» код, читая содержимое файла, которое обходит разрешения файловой системы «execute».

13
ответ дан 6 August 2018 в 04:01
  • 1
    Я понимаю вашу мысль. Но тогда это для группы или мира или для обоих? – Ashfame 10 February 2011 в 23:04
  • 2
    @Ashfame Если вы установите разрешение на выполнение, сценарий может запускаться непосредственно пользователями, у которых есть это разрешение, независимо от того, есть ли у них это на основе группы, мира или владельца. Но даже люди без разрешения на выполнение могут выполнить его, вызвав другую программу (например, bash), чтобы выполнить выполнение - чтобы заблокировать это, вы также должны были бы удалить свое разрешение read. – j-g-faustus 10 February 2011 в 23:37
  • 3
    If you set the executable permission, the script can be run directly by users who have that permission - whether they have it on a group, world or owner basis Но как разрешение предоставляется другим пользователям, проверяя разрешение на выполнение? И у меня есть второй момент. Вы имеете в виду отнять их разрешение на чтение скрипта, чтобы они не могли обработать его через bash. Правильно? – Ashfame 10 February 2011 в 23:58
  • 4
    @Ashfame На точке разрешения чтения да. О том, как вы могли бы назвать что-то вроде sudo chmod g+x myfile.sh в терминале, чтобы добавить разрешения на выполнение для группы файлов. См. [D0] Учебник по разрешению файлов . Чтобы управлять разрешениями для нескольких пользователей одновременно, вы должны использовать группы, например, Управление группами . – j-g-faustus 11 February 2011 в 01:43
  • 5
    что я имел в виду, когда мы добавляем исполняемые разрешения в GUI, то это для кого? владелец / группа / мир? – Ashfame 11 February 2011 в 01:57

Другие вопросы по тегам:

Похожие вопросы: