> Вот это уже костыль!
> А если мне, таки, нужен вызов system?!

чуть выше уже писал: "Там где действительно нужно запускать что то из оси, делается гейт, - пых сбрасыет запрос (через банальный файл флаг или REST API) и со стороны оси выполняются только WHITELISTED команды и возвращают результат"

Зачем вам system, если система окажется сконфигурирована таким обазом, что и вызывать через system нечего будет (stripped down chrooted enviroment)?

> И мне что каждую в PHP ф-ию таким способом проверять, чтобы убедится,

да, проверять. Проблема  считать disabled_functions и проверить что перекрыто? Или проблема контактировать проджект менеджера и запросить (обоснованно) доступ к нужным функциям?

> что упоротый админ не отключил её?

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

>> а вот запрет выполнения eval-a, это уже защита хоста,
> Защита какого хоста и от кого?

вы пишите на PHP и не знаете от кого защищают хосты?
От хакеров, от засланных казачков, от дурости и ошибок, etc...

> Если Вы имеете ввиду защиту виртуального хоста от самого себя, то это
> просто маразм.

Вы называете маразмом кучу взломаных сайтов в интернете ???
Вообще, это называется - security.

> А может всё-таки стоит уважать права пользователя!

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

> Если сервер выделил для виртуального
> хоста место, так сказать его домашнюю директорию, то он вправе в
> ней делать что пожелает!?

Нет, это не правильно. Если вы пишите программу для закрытой домашней локальной сети, то действительно фиг ней с секьюрностью.

Если же это комерческое приложение выпущенное в дикий интернет, то ваша "домашняя" директория должна иметь как минимум 3 уровня защиты на базе файловой системы - это вы,  как веб девелопер с правами писать и читать везде, PHP-FPM юзер которого вы должны ограничить только на чтение и назначить его на php файлы и открыть права на запись только в data директории, ну и others (веб серер) с правами ready only. В такой конфигурации, даже если хакер найдет лазейку, он не сможет изменить PHP файлы, а скинуть сpaнь в дата директорию с надеждой потом выполнить - тоже не получится, потому что в конфигах веб сеpвака  будет запрещена интерпритаця чего либо (php,perl,bash,pyhton...) в data директории

> А если у меня, внезапно, веб-админка, которая мониторит и управляет запуском какого-то
> сервиса, который является непосредственно частью проекта, например отвечающего за обновление
> страницы в реальном времени, аля web-sockets, или запускающий сli-скрипт для рассылки
> уведомлений, или чистки чего-либо?

нельзя это делать, у вас должен быть барьер между web application и операционной системой, самый тривиальный пример это RPC через файловую систему, тогда можно будет перекрыть кислород к полному функционалу операционки со стороны интернета и в тоже время безопасно выполнить то, что вам требуется.

> В пределах домашней директории ДА! Так везде!

Я правда не хочу вас обидеть, но shared hostings и VPS типа "сделай сам по хавтушкам" - это далеко не везде, в серьезной конторе вы не встретите такого безобразия, это все равно что работать все время из под root-a или администратора а винде. Не правильно это, поэтому и придумали разграничение уровня доступа.

>> PHP - интернет facing язык и конфигураця настройки должна ...
> ...предсказуемой и внезапно не влиять на базовые возможности и ф-ии языка!

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