Здесь abc
имя пользователя и ak.sh
файл, который я хочу получить все полномочия. Добавила следующая строка на вершине sudoers.tmp
как который я открылся sudo visudo
:
abc ALL=NOPASSWD: /home/abc/ak.sh
ak.sh содержит:
#!/bin/bash
sudo cat /dev/tty13
Когда я выполняю файл сценария, он просит у меня пароль.
Необходимо на самом деле использовать sudo
чтобы правило sudoers было полезно. Также:
sudo /home/abc/ak.sh
cat
как это:abc ALL=NOPASSWD: /bin/cat /dev/tty13
и выполненный sudo cat /dev/tty13
в сценарии.Принятие Вашего метода освобождения пароля работает тот же путь изменяющийся sudoers, необходимо назвать СЦЕНАРИЙ с sudo, не команду В сценарии. Или изменение sudoers. Другими словами:
sudo /home/abc/ak.sh
то, что Вы освободили от требования пароля, нет cat
. Все еще необходимо использовать sudo
но если Вы сделали его правильно, Вы не будете обязаны вводить передачу.
@muru
Почему это, кажется, мне лучше к паролю, освобожденному сценарий, СОДЕРЖАЩИЙ команду кошки, а не саму кошку:
$ ls / | grep secrets
secrets_root_does_not_want_to_share_.txt
$ # hmmm, that looks interesting . . .
$ cat /secrets_root_does_not_want_to_share_.txt
cat: /secrets_root_does_not_want_to_share_.txt: Permission denied
$ # Curses! My evil plans are foiled because:
$ stat /secrets_root_does_not_want_to_share_.txt | grep 'Access: ('
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
$ # But wait! I'm pass exempted! So:
$ sudo cat /secrets_root_does_not_want_to_share_.txt
Oh, my. Sensitive stuff is exposed to ordinary users.
Освобождение пароля sudo cat
не так опасно как, например, освобождение пароля sudo echo
но это, действительно кажется, мне довольно плохая практика.
Добавленный позже для обращения к скептицизму Muru относительно эквивалентности sudo cat
когда пароль не истек от предыдущего использования sudo к sudo cat
когда кошка была освобожденным паролем:
Я добавил правило к началу моего раздела освобождения передачи в/etc/sudoers как так:
me THIS_LOCAL_SYS=(ALL)NOPASSWD:/bin/cat, . . . [many other rules, separated by commas]
Затем в новом терминале:
$ # Demonstrating that password is not un-expired from previous use of sudo:
$ sudo ls /root
[sudo] password for j:
$ stat /secrets_root_does_not_want_to_share_.txt|grep 'Access: ('
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
$ cat /secrets_root_does_not_want_to_share_.txt
cat: /secrets_root_does_not_want_to_share_.txt: Permission denied
$ # And rightly so, but with pass exempted sudo:
$ sudo cat /secrets_root_does_not_want_to_share_.txt
Oh, my. Sensitive stuff is exposed to ordinary users.
$
Так, да, они эквивалентны, как они должны быть; да, я ДЕЙСТВИТЕЛЬНО понимаю, как sudo работает - я только отредактировал тот файл несколько сотен раз; и да, плоскость освобождения пароля/bin/cat, вместо сценария, содержащего кошку, является необоснованной практикой с точки зрения безопасности. Снова, не катастрофическая глупость то освобождение пароля sudo echo
или sudo vi
был бы, но все еще плохая идея.