Как отмечали другие, права доступа к файлам являются битовой маской. Система не делает все возможное, чтобы предотвратить использование странных или бесполезных комбинаций: бесполезное не означает вредное.
Если у меня есть только разрешение на запись, означает ли это, что я могу добавлять или заменять содержимое файла, но не читать текущее содержимое?
Да.
Если я только для чтения, почему я не могу просто скопировать файл и выполнить его тогда?
Вы можете, за исключением. Копирование "привилегированного" файла (файла с битами setuid/setgid или возможностями файлов Linux) не приведет к копированию этих свойств. Вам также нужно место для его копирования, и есть возможность иметь систему, в которой раздел /home запрещает выполнение файлов из него.
То же самое можно сделать без копирования, вручную вызвав соответствующий интерпретатор. Например, вы можете запускать сценарии оболочки через sh /path/to/script даже если они не исполняются. Двоичные файлы в Linux также имеют интерпретатор /lib/ld-linux.so .
И если они имеют только разрешение на исполнение, что это значит? Разве выполнение файла не требует от вас его просмотра?
Да, но это проверяется после того, как бит setuid обработан. Если вы выполняете программу setuid, она будет иметь привилегии владельца, поэтому только владелец должен +r.
Для каталогов +x имеет другое значение (это позволяет вам перемещаться по папке, то есть получать доступ к элементам внутри). Если вы знаете точное имя файла внутри, вы можете получить к нему доступ, просто +x, а не +r в каталоге.
Где это имеет значение, если дано разрешение на выполнение? выполнение файла .txt не имеет смысла. В Windows есть, например, .exes, .bats и так далее. В системах Unix я знаю только .sh. Существует ли определенное количество расширений, определяющих исполняемые файлы?
Исполняемость определяется не именем файла, а его содержимым. (В конце концов, вы выполняете содержимое, а не имя.)
Файл может быть исполняемым, когда ядро знает, как загрузить его как единое целое. Ядро Linux понимает двоичные файлы ELF, а также файлы "script" с #! заголовок как их первая строка. (То же самое для большинства других Unix-подобных операционных систем.) Поэтому имеет смысл использовать +x только для этих двух типов файлов.
Например, если файл скрипта начинается с #!/bin/sh , затем выполнение его аналогично ручному запуску /bin/sh myscript.sh . То же самое можно применить к Python или Perl, Ruby, TCL, C #, Node/JavaScript или любому другому языку. (Опять же, обратите внимание, что суффикс имени файла не имеет значения - только магический заголовок.)
Преимущество состоит в том, что ваша система может иметь команды, написанные на разных языках, и вы можете использовать их, не заботясь о том, какой интерпретатор использует каждая команда.
Windows находится в аналогичной ситуации. Он также имеет тот же бит разрешения «исполняемый файл», и хотя графический интерфейс требует суффикса .exe в именах файлов, реальное ядро заботится только о содержимом файла. (Windows использует двоичные исполняемые файлы MZ/PE и не поддерживает #! для скриптов.)
