noexec на разделе? selinux или подобное?

echo 'echo lol' > t
sh t

noexec на корне? Шутишь, небось?

sh t работает, да

Почему могло поломаться?

Потому что никогда не работало и не должно работать.

И да, «с утра все работало»

окэй, как надо?

Возможно, что я не прав, но...

Надо дать права на исполнение бинарнику

chmod +x t

Надо добавить в файл shebang.

chmod 755 включает в себя chmod +x :)

OMF, оно работает! А я думал, что баш без строчки «#!/bin/bash» пошлет нафиг.

Ок, не знал, я же погроммист — далек от этого вашего сисадминства. =)

ты еще предложи sudo сделать

selinux какой-нибудь случаем не включен?

Да, и правда. Ящитаю, это баг. Если у файла нет ELF-заголовка или shebang, то он не должен выполняться же.

Ясен пень.

А я думал, что баш без строчки «#!/bin/bash» пошлет нафиг.

по дефолту оно /bin/sh вызывает. А «нет прав» может быть потому, что само /bin/sh не исполняемое. Если его нет, ЕМНИП напишет «не найдено».

# env |grep SHELL=
SHELL=/bin/bash

Но наверное ты прав.

нет, это документированное поведение. Вот только не помню где пруф...

не, с утра не было

SHELL=/bin/bash

Но наверное ты прав.

неа. именно /bin/sh.

может мне смайлики ставить?

алсо, $SHELL и есть то самое «оно», которое «по дефолту оно /bin/sh вызывает». И, теоретически, поскольку само является шеллом, может не вызывать sh а попытаться выполнить само.

Ладно, это все забавно, но почему в доступе-то отказано?

алсо, $SHELL и есть то самое «оно», которое «по дефолту оно /bin/sh вызывает». И, теоретически, поскольку само является шеллом, может не вызывать sh а попытаться выполнить само.

вообще-то /bin/sh и /bin/bash это разные вещи на самом деле (у меня /bin/sh это ссылка на bash), а $SHELL это вообще говоря переменная, в которой полный путь к _текущей_ оболочке. Почему ты думаешь, что будет вызвано именно $SHELL - мне непонятно. ЕМНИП должно вызываться /bin/sh, но мне лениво проверять, что вызывается на самом деле (ибо у меня /bin/sh -> bash)

Ладно, это все забавно, но почему в доступе-то отказано?

что пишет ls -l /bin/sh

а что ls -Ll /bin/sh

?

А «нет прав» может быть потому, что само /bin/sh не исполняемое.

Не-а. Потому, как

sh t работает, да

noexec на разделе, где файл лежит, не обязательно корень. Смотри:

# touch /dev/shm/test
# ln -s /dev/shm/test ./t
# echo "echo lol" > t
# ./t
-su: ./t: Отказано в доступе
# sh t
lol
# mount | grep shm
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)

Забыл chmod 755 ./t , но он ничего не меняет.

Ты видел хоть раз, чтобы директория /root не находилась в корне?

Например, в GoboLinux она лежит в /Users.

// мимокрокодил

будет вызвано именно $SHELL

Нет. Он _может_ быть вызван. Теоретически. Поскольку «$SHELL это вообще говоря ... полный путь к _текущей_ оболочке. »

GoboLinux

Это же вообще жесть!

работает. исправил ОП пост

Cпециально же написал: /root

А я не менее специально написал, что ./t может быть симлинком на файл, который может находиться где угодно. Поведение при этом такое, как и описано. ./t - отказано в доступе; sh t - выполняется.

лежать она может где угодно, но это должен быть корневой раздел, иначе смысла нет.

и да, GoboLinux не FHS

не может, я не писал ln

А я не менее специально написал, что ./t может быть симлинком на файл, который может находиться где угодно. Поведение при этом такое, как и описано. ./t - отказано в доступе; sh t - выполняется.

в принципе да, sh t выполнится в любом случае, если конечно sh - это исполняемый файл. Что такое t роли не играет. А вот ./t - тут важно и исполняемость sh и /bin/sh (тоже разные вещи на самом деле, у меня /bin почти в конце $PATH)

потому что шебанга нет

Такое поведение документировано, но редко используется. Т.е. в этом случае должен использоваться шел по умолчанию, а он бывает разным.

Не важно.

# echo '#!/bin/sh'>t ;'echo lol' >>t
# chmod 755 t
# ./t
bash: ./t: Отказано в доступе

Эти погромисты ничего не понимают в кампутерах и системах под которые пишут. Ок.

А что за система/ядро? Слышал, что в 3.5 что-то изменилось. Проверить не могу.

strace ./t

что говорит?

# strace ./t
execve("./t", ["./t"], [/* 89 vars */]) = -1 EACCES (Permission denied)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7facb9145000
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: Permission denied\n", 32strace: exec: Permission denied
) = 32
close(3)                                = 0
munmap(0x7facb9145000, 4096)            = 0
exit_group(1)                           = ?

Как это прочитать?

М-да. На мой взгляд, это поведение порочно, документировано оно или нет.

Тяжелое наследие unix-ов ;) Меня на соляре это достало, но ничего не сделаешь из-за обратной совместимости.

реально очень похоже что у тебя execute не стоит на файле.

давай

ls -lh ./t

я его в теме не видел пока

да, похоже. Но

drwxr-xr-x  5 root root   4096 Окт 15 13:56 .
drwxr-xr-x 64 root root   4096 Окт 15 12:23 ..
-rwxr-xr-x  1 root root     38 Окт 15 15:56 t

чет он у тебя много весит... «echo lol» - это 8 байт

вообще хрень какая-то... должно бы работать. Разве что действительно selinux какой-нибудь блокирует.

Надо shebang и путь к интерпретатору скрипта в начало файла добавить (#!/bin/bash)