/usr/bin/vim по сравнению с/bin/vim
Не делайте FTP как корня: протокол FTP передает идентификатор пользователя и пароль как (незашифрованный) открытый текст. Если кто-либо ловит последовательность входа в систему FTP, и существуют снифферы, которые делают точно, что, у них есть Ваш пароль root.
Это из пути, это могло быть что-либо. Необходимо будет назвать программное обеспечение FTP-сервера. Некоторые не позволят вход в систему, если локальная оболочка пользователя (на машине, выполняющей FTP-сервер), не появится в /etc/shells, например. Некоторые FTP-серверы имеют очень сложные схемы ACL о том, что позволить и что запретить.
Некоторые основы поиска пути
Когда вы запускаете команду, не содержащую косой черты, такую как vim , оболочке необходимо знать, какой файл (или встроенную функцию / функцию оболочки) выполнять. Она находит это, следуя пути поиска , определенная в переменной среды PATH . Переменная PATH представляет собой список путей, разделенных двоеточиями, и оболочка будет искать имя команды в каждом из этих путей в указанном порядке.
Например, базовый ПУТЬ из установки Debian выглядит следующим образом:
/usr/local/bin:/usr/bin:/bin
В этом случае вы сначала найдете / usr / bin / vim , как показано вывод , в котором vim и вводят vim .
Теперь, когда вы запускаете команду через sudo , где указаны параметры env_reset и secure_path , sudo сбрасывает поиск путь к содержимому secure_path перед выполнением переданной команды. Это означает, что команда, которую вы запускаете через sudo , может иметь другой путь поиска и может найти другой исполняемый файл, не выполняя команду напрямую.
Например, базовый sudo PATH от Debian:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Ваш сценарий
Я подозреваю, что здесь происходит ваш secure_path либо указывает порядок, в котором / bin предшествует / usr / bin , или последний не существует вообще. В этом случае оболочка будет искать vim и в конечном итоге найти / bin / vim , поскольку он существует. И если в белый список включен только / usr / bin / vim , то запуск первого может быть запрещен.
Вы можете проверить текущий ПУТЬ с помощью echo $ PATH . Вы можете проверить sudo ПУТЬ с помощью sudo env | grep ПУТЬ . Если ваш администратор установил белые списки, разрешающие только vim , вы можете войти в sudo vim и выполнить команду : echo $ PATH .
Вы можете обойти это, указав абсолютный путь, например sudo / usr / bin / vim .
Почему существует search_path ?
Что касается , почему sudo устанавливает другой путь, рассмотрите этот сценарий атаки:
Ваш PATH - это просто переменная среды. Его можно настроить разными способами, возможно, невидимыми для пользователя. В нем могут быть небезопасные каталоги, в которых любой может писать в них. Если кто-то создаст вредоносный исполняемый файл с именем вроде ls , то при запуске ls вы будете выполнять этот файл вместо настоящего ls .
Но ущерб будет ограничен тем, к чему у вашей учетной записи есть доступ. Теперь предположим, что вы запускаете sudo ls - если ПУТЬ берется из вашего текущего ПУТЬ , а не сбрасывается, то теперь вы запускаете вредоносный исполняемый файл с root-привилегии - атака на повышение привилегий. Гораздо больший ущерб, чем просто работа в качестве собственного пользователя.
Теперь вы можете утверждать, что злоумышленник, имеющий возможность помещать файлы в ваш ПУТЬ или иным образом изменять ваш ПУТЬ , уже может нанести большой ущерб. И вы, наверное, правы. С обеих сторон есть мнения о полезности secure_path , которые я не буду здесь вдаваться.