Отказано в доступе

он уже пробовал

Ну вы блин даете, strace пытается прочесть ASCII текст как бинарный код...

потом делал

# echo '#!/bin/sh'>t ;'echo lol' >>t

оп менять было поздно, вот.

Не верю. noexec на исполнение скриптов не влияет, так как они интерпретируются сторонней программой. У меня вот все работает

тред то почитай, там и noexec нет

хоть это ничего и не меняет, но надо было:

# echo '#!/bin/sh'>t ; echo 'echo lol' >>t

-rwxr-xr-x 1 root root 19 Окт 15 16:47 t

теперь все точно

Если ничего не поможет, стоит посмотреть выхлоп

test@home:~$ strace -oout sh 
$ ./t
lol
$ exit

P.S. подозреваю, что что-то напутано в binfmt-support

bash: ./t: Отказано в доступе

Самое странное — это ошибка «Отказано в доступе». В худшем случае должен быть «Exec format error» или что-то вроде «не могу запустить бинарный файл». Но «Отказано в доступе» — это явно кто-то мешает.

Какой дистрибутив? Установлен ли selinux? Что пишет `sestatus`? Установлен ли AppArmor? Что пишет `apparmor_status`?

Eсли файл удалить и снова проверить? Что пишет:

rm -f t; echo 'echo lol' > t; chmod 755 t; ./t

Бинарные файлы в этом же месте запустить получается? Что пишет:

rm -f t; cat /bin/ls > t; chmod 755 t; ./t

linux-6:/root # ./t

Ничего не поломалось, так задумано с самого начала, чтобы не запускалась всякая гадость из мест отсутствующих в переменной PATH.

у ТС всё как раз наоборот

у ТС всё как раз наоборот

У него в $PATH имеются "." и «/root» ? OMG!!

Да.

Выхлоп echo $PATH в студию!

# echo $PATH .:/root:/home/user/bin:/usr/local/bin:/usr/bin:/sbin:/usr/sbin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games

Можно также увидеть вывод остальных команд?

cd /root
sestatus
rm -f t; echo 'echo lol' > t; chmod 755 t; ./t
rm -f t; cat /bin/ls > t; chmod 755 t; ./t

селинукса нету, все работает, кроме ./t

# rm -f t; cat /bin/ls > t; chmod 755 t; ./t
bash: ./t: Отказано в доступе

то есть, даже читать не пробует

# echo $PATH .:/root:/home/user/bin:/usr/local/bin:/usr/bin:/sbin:/usr/sbin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games

Попробуй так: # /root/t
Должно работать, а "./t" работать не должно.

во-первых, с хрена ли не должно, если все время работало? во-вторых:

# /root/t
bash: /root/t: Отказано в доступе

За всякий случай уберите точку из PATH. Это создает проблемы с безопасностью.

root:123@127.0.0.1

Но все равно спасибо

С binfmt-support точно все в порядке? Удалось повторить ситуацию

test@home:~$ ./test
bash: ./test: Отказано в доступе
test@home:~$ sh ./test
123
test@home:~$ sh test
123

Отказано в доступе (комментарий)

если я тебя правильно понял. Все эксперименты только завтра.

Как уже сказал анонимус, очень странно, что у вас execve() возвращает EACCES (Permission denied), должно быть «ENOEXEC (Exec format error)»

То есть баш сначала всегда делает execve() на файл, если получает в ответ «ENOEXEC», то читает начало файла, если там «#!», то вызывает соотв. интерпретатор, иначе считает, что это shell-скрипт.

Если в начало файла добавить «#!/bin/bash», то начинает работать?

С утра с профилями apparmor что-нибудь делали?

echo $PATH .:/root

Ничего себе…

А можно заодно и выхлоп mount?

Может это NX-защита срабатывает так?

Нет, я просто добавил обработчик нового бинарного формата, что то типа:

cat /root/lol
package lol
interpreter /home/test/sh
magic echo

Вначале я подумал, что у рута битый шел. Но тогда бы он не смог залогинится. Хотя, если это убунту, можно сделать sudo bash

Проверяется

getent passwd root
root:x:0:0:root:/root:/bin/bash

# echo $PATH
.:/root: <...>

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

Поставь систему заново и больше не делай того что не положено. Тогда всё будет работать нормально.

Нет, я просто добавил обработчик нового бинарного формата [...] Т.е. заставил все файлы, начинающиеся с echo исполнятся /home/test/sh.

Это могло бы объяснить баг с шелл-скриптом. Но не объясняет:

# rm -f t; cat /bin/ls > t; chmod 755 t; ./t
bash: ./t: Отказано в доступе

Обработчики бинарных форматов не действуют на elf или a.out. Т.е. (в случае, который я показал) будут нормально работать бинарники и скрипты, которые не начинаются с echo.

Хотя сейчас думаю, что неправильно указан рутовский шел, но ТС переходит под рута через sudo bash, поэтому багов не видит.

Обработчики бинарных форматов не действуют на elf или a.out. Т.е. (в случае, который я показал) будут нормально работать бинарники и скрипты, которые не начинаются с echo.

Тогда почему копия ls тоже НЕ запускается?

Хотя сейчас думаю, что неправильно указан рутовский шел, но ТС переходит под рута через sudo bash, поэтому багов не видит.

Тогда почему копия ls тоже НЕ запускается?

то есть, даже читать не пробует

Интересно. Мистика. Правда, очень интересно... Может всё-таки есть что-то необычное в текущих опциях монтирования? Что рассказывает?:

awk '$2 == "/" || $2 == "/root"' /proc/mounts

И просто для порядка, что пишет с чистым PATH-ом? Будут ли работать те же самые команды после:

export PATH=/bin:/usr/bin

Честно говоря не увидел где ТС пытается запустить копию ls.

Можно предположить что /root это отдельная партиция, монтируемая с noexec, но ИМХО это нереально.

Честно говоря не увидел где ТС пытается запустить копию ls.

По моей просьбе, тут: Отказано в доступе (комментарий)

Можно предположить что /root это отдельная партиция, монтируемая с noexec, но ИМХО это нереально.

Да мне тоже в это слабо верится, но мало ли, может у него туда tmpfs с noexec смонтирован. На всякий случай просьба показать нужные строки из /proc/mounts тут.

По моей просьбе, тут

Да, ступил.

А apparmor такое выкинуть может? Я им никогда не пользовался. Иначе мистика ;(

И PATH какой то левый. Похоже над системой кто то издевался. Случайно это сделать невозможно.

А apparmor такое выкинуть может?

Вроде, не должен, там же ни один профиль не загружен.

Иначе мистика ;(

В общем, ждем ответа ТС на вопрос про /proc/mounts, а там уже будем дальше гадать. Если в /proc/mounts проблему не найдём, то ТСа надо будет произвести в шаманы за достижение в линуксе невозможного. :)

И PATH какой то левый. Случайно это сделать невозможно.

PATH вполне мог быть сделан таким специально. Возможно ТС хранит скрипты в /root-е и часто запускает их оттуда, потому он и заметил баг.

PS: Кроме noexec есть много маловероятных причин таких глюков. Но я надеюсь, что это не они.

Нет, ничего такого не делал. И да, я не админ, выхлоп strace не понял, но «EACCES (Permission denied)» мне тоже не понравилось. Шебанг уже обсудили, он не влияет.

Там включена точка.

Так и скажи: ТС — ССЗБ. Это надо ж додуматься, включать в PATH первым номером текущую директорию, да еще в рутовском PATH!

echo $PATH .:/root

Ничего себе…

Ничего особенного, вообще-то. PATH=.:/root:$PATH Хорошо тем, что изменения действуют до первого logout.

Я все-таки не совсем идиот, если бы очевидной причиной была моя собственная криворукость, я бы упомянул об этом.

Я тут подумал, а к тебе на сервер никто не вламывался? Я помню был руткит, который подменял системные top, ls, sh и другие базовые утилиты, после чего все они скрывали зловредные процессы.

Может что-то из этой серии? не родной ls, sh? чексуммы проверить и сравнить с репозиторием?

Сочинителям руткитов даже выдумывать ничего не надо: ты сам все сделал за них. И юзер какой-нибудь возьмет, да впихнет в хомяк вайлик ls с содержанием nohup rm -rf /, вот ты и приплывешь, когда попытаешься посмотреть содержимое его директории ☺

И все-таки покажи выхлоп mount

Ничего особенного, вообще-то.

Так всё-таки, что в том магическом рутовом шелле пишет команда?:

awk '$2 == "/" || $2 == "/root"' /proc/mounts

Или хотя бы команда:

grep ' / \| /root ' /proc/mounts

выхлоп mount

Забыл. Там ext4. В fstabs указан defaults. mount показывает rw, relatime, barrier=1, data=ordered и все. Завтра уточню

Т.е. заставил все файлы, начинающиеся с echo исполнятся /home/test/sh

ок, завтра проверю