Не мог дать разрешение через sudoers к сценарию, получающему доступ/dev/tty13

Здесь abc имя пользователя и ak.sh файл, который я хочу получить все полномочия. Добавила следующая строка на вершине sudoers.tmp как который я открылся sudo visudo:

abc ALL=NOPASSWD: /home/abc/ak.sh

ak.sh содержит:

#!/bin/bash
sudo cat /dev/tty13

Когда я выполняю файл сценария, он просит у меня пароль.

0
задан 10 July 2017 в 23:58

2 ответа

Необходимо на самом деле использовать sudo чтобы правило sudoers было полезно. Также:

  1. Используйте текущее правило sudoers и работайте sudo /home/abc/ak.sh
  2. Используйте другое правило, для которого Вы упомянули, но с полным путем cat как это:
    abc ALL=NOPASSWD: /bin/cat /dev/tty13 и выполненный sudo cat /dev/tty13 в сценарии.
1
ответ дан 2 November 2019 в 23:32

Принятие Вашего метода освобождения пароля работает тот же путь изменяющийся 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 был бы, но все еще плохая идея.

-1
ответ дан 2 November 2019 в 23:32

Другие вопросы по тегам:

Похожие вопросы: