Sudo не может видеть исполняемые файлы с символьными связями в пути

Question

В CentOS 7 я установил некоторые исполняемые файлы в /opt/app-version/bin/executable . Эти исполняемые файлы имеют следующие разрешения:

rwxrwxr-x. 500 500

Владение каждым каталогом в пути /opt/app-version/bin/ составляет 500 500 --except /opt , который является root root .

Мой первый вопрос: что это за 500 500 бизнес? Учитывая, что я установил исполняемые файлы с помощью sudo , разве владелец и группа не должны быть root?

Я выполнил следующую команду от имени пользователя root для создания символических ссылок на исполняемые файлы в /usr/local/bin/:

ln /opt/app-version/bin/executable /usr/local/bin/executable --symbolic

Я могу запускать executable из командной строки как обычный пользователь, но не как обычный пользователь, использующий sudo .

Запущенный sudo executable возвращает sh: executable: command not found .

Запуск sudo echo $PATH показывает, что /usr/local/bin/ находится в $PATH для сред sudo. (Или это? Я вижу содержимое $PATH для среды суперпользователя или $PATH для среды пользователя с именем sudo? Создает ли CentOS новую среду для команд, запускаемых с помощью sudo , или он просто запускает команду в среде вызывающего? )

Запуск sudo ls -la /usr/local/bin/executable возвращает список executable в /usr/local/bin/ с владельцем lrwxrwxrwx. 1 root root . ( Действительно ли ln --symbolic создает глобально редактируемые ссылки по умолчанию? Разве это не ужасная идея? Насколько я понимаю, это показывает, что sudo должен запускать executable .

Что мне не хватает?

Answer 1

Если посмотреть сначала на 500 500 , если вы восстановите из архива tar (среди прочего), владелец и группа будут сохранены из системы, в которой был создан архив: я предполагаю, что установщик делает это, и если восстановленный пользователь или группа не существует в вашей системе, числовое значение отображается.

Глядя теперь на PATH , я воспроизвел это в Ubuntu, и кажется, что sudo изменяет PATH: в вашей команде sudo echo $PATH PATH переменная PATH была расширена в исходной оболочке перед вызовом sudo . Существует файл /etc/sudoers с записью "defaults secure_path="..." , и это, похоже, то, что используется.

Если вы используете sudo sh -c 'echo $PATH' вы получите лучшее представление об используемом PATH . Обратите внимание, что я намеренно использовал sh вместо bash , чтобы обойти некоторые файлы инициализации, которые могут что-то изменить, хотя sh , конечно, будет иметь некоторые свои собственные.

В Ubuntu строка secure_path содержит /user/local/bin , но CentOS может отличаться (оба являются производными от Debian, но, согласно man sudoers SELinux может переопределить некоторые записи). Насколько я вижу, у вас есть как минимум четыре варианта:

• Измените secure_path для включения `/usr/local/bin '.
• Поместите ссылку в один из каталогов, определенных в secure_path .
• Используйте su -c "{command} {parameters}" вместо sudo {command} {parameters} .
• Используйте sudo -s для получения root- bash с той же инициализацией PATH что и в исходной оболочке, затем вызовите оттуда свой исполняемый файл и затем завершите работу.

Я также нашел много обсуждений и некоторых других возможных решений здесь.