Если не сконфигурировано странно, sudo
хочет аутентификацию при запуске. Обычно он предназначен для интерактивного запуска.
Предполагая, что скрипт / glassfish3 / bin / asadmin принадлежит root, , вы можете установить его права доступа к файлу 6755. Это делает то, что вы, вероятно, имели в виду sudo
, чтобы сделать , Конечно, это также может быть опасно и может представлять угрозу безопасности.
(кстати, @ jcomeau_ictx прав. Вы должны проверять журналы, как он предлагает.)
Обновление для архива: Вышеприведенный ответ, к счастью, решил непосредственную проблему ОП, поэтому мы оставим это в покое. Однако, так как этот ответ останется в архиве, и другие могут посмотреть его позже, я должен добавить к нему больше.
Один может изменить права доступа к файлу для любого исполняемого файла на 6755, но это не всегда хорошая практика. Результатом таких разрешений является (а) позволить любому запускать исполняемый файл с (б) полными привилегиями владельца исполняемого файла. Иногда это именно то, что вы хотите, но смотрите: в случае OP, /glassfish3/bin/asadmin
с такими разрешениями теперь может вызываться любым, с любыми аргументами, с полными привилегиями root. Если это не то, чего вы хотите, тогда вам необходимо принять дополнительные меры.
Возможны несколько способов получения дополнительной помощи. Один из них выглядит следующим образом.
- Оставьте исполняемый файл с правами доступа к файлу 755.
- Напишите и скомпилируйте небольшую оболочку, программу, которая использует
execv()
из unistd.h для запуска исполняемого файла.
- Если это практически возможно, не позволяйте оболочке принимать аргументы; в противном случае пусть его аргументы будут настолько жесткими и жесткими, насколько это возможно. Пусть оболочка строго контролирует аргументы, передаваемые исполняемому файлу.
- Пусть обертка принадлежит root, , но используйте
chown
, чтобы назначить ей подходящую группу, в состав которой не входят пользователи. Вы можете предпочесть создать новую группу для этой цели, но если вы сканируете файл /etc/group
в своей системе, вы вряд ли найдете уже существующую подходящую группу. Для справки, вы можете перечислить команды, уже принадлежащие к группам специального назначения в вашей системе, с помощью ls -l /bin /usr/bin | grep -vE '^([^[:space:]]+[[:space:]]+){2}(root[[:space:]]+){2}'
или подобного.
- Дайте файлу обертки права доступа 6754, что делает его неисполнимым, кроме рассматриваемой группы.
- Допустить вызывающий сценарий к группе и дать разрешения файлу вызывающего сценария 2755.
Если вызывающий скрипт уже принадлежит группе, вы, вероятно, можете просто использовать одну и ту же группу повсюду.
Возможно несколько вариантов техники, и маловероятно, что вы будете использовать в точности ту, которая указана выше, но если вы прочитаете man-страницу и / или информационную запись в команде chown
и узнаете подробности о правах доступа к файлу, и если вы немного поэкспериментируете, вы сможете разработать решение, которое будет работать для вас, не создавая угрозы безопасности.