Как к паролю - защищают сценарий на Linux?

С wmctrl:

wmctrl -a Stardict

С xdotool:

xdotool windowactivate $(xdotool search --class Stardict)

Я использовал Stardict для класса окна проверьте, что это правильно с xprop (выполненный xprop в терминале затем нажимают на непредставленное в виде значка окно Stardict и проверяют WM_CLASS строка).

2
09.07.2013, 23:04
3 ответа

Sudo мог бы быть способом пойти.

Имейте своего владельца сценария и исполняемый файл определенным пользователем и не предоставляйте доступ от других пользователей, 700 полномочий, например.

Во-вторых, отредактируйте свое sudoers использование файла visudo и добавьте строку как следующее:

%your_group ALL=path_to_script/script

Все пользователи, которые способны к запущению скрипта, должны быть добавлены к your_group.

Так, кто бы ни не часть your_group, не сможет запустить скрипт. Альтернатива может быть для Вас к определенному просто именем пользователя.

username ALL=path_to_script/script
5
27.01.2020, 21:55
  • 1
    , Вы обычно не должны редактировать Ваш /etc/sudoers зарегистрируйте непосредственно, используйте инструмент visudo сделать редактирования. –  slm♦ 09.07.2013, 10:22
  • 2
    обновил ответ с инструментами для редактирования. спасибо @slm –  BitsOfNix 09.07.2013, 10:42
  • 3
    Необходимо только использовать visudo отредактировать /etc/sudoers. sudoedit не проверит синтаксис файла. спасибо –   09.07.2013, 14:27
  • 4
    я стал удачливым с sudoedit, не повреждая его, обновило ответ. спасибо –  BitsOfNix 09.07.2013, 14:35
  • 5
    Вопрос, как спросили не призывает или извлекает выгоду из sudo: для держания учетных данных отдельно от определенных пользователей все это, взятия не должны давать им разрешение чтения на файле, который содержит учетные данные. –  Gilles 'SO- stop being evil' 10.07.2013, 04:27

Необходимо удостовериться, что пароль только читаем авторизованными пользователями. Не храните пароль в сценарии, храните его в отдельном файле, который Вы читаете из сценария. Намного легче управлять полномочиями этот путь. При хранении учетных данных в сценарии трудно быть уверенным, где они закончат: они могут быть непреднамеренно скопированы вокруг, они должны быть введены в управление версиями и т.д.

Разделение учетных данных из сценария обладает вторым и возможно более важным преимуществом. Это разделяет “разрешение выполнить сценарий” из “разрешения получить доступ к ресурсу”, который хорош, потому что Вы действительно не пытаетесь препятствовать тому, чтобы люди выполнили Ваш сценарий, Вы пытаетесь препятствовать тому, чтобы люди получили доступ к ресурсу. Так устанавливает полномочия на файле паролей соответственно, и Вы будете установлены.

Простой способ управлять полномочиями состоит в том, чтобы создать группу и поместить пользователей, которым разрешают получить доступ к ресурсу в той группе. Давайте назовем группу seniors, и скажите это пользователи alice и bob позволяются получить доступ к ресурсу. Создайте названную группу seniors (например. addgroup seniors), и добавьте пользователей к группе (например. adduser alice seniors; adduser bob seniors). Сделайте файл паролей принадлежавшим группе seniors и читаемый только группой.

chgrp seniors password.txt
chmod u=rw,g=r,o= password.txt    # or chmod 640 password.txt for short

Возможно, Вы хотите, чтобы некоторые пользователи смогли выполнить сценарий, но не иметь произвольную выборку к ресурсу. Вы не упоминаете это в своем вопросе, но я объясню, как он может быть сделан на всякий случай.

Предположим что пользователи charlie и dominique должен смочь выполнить тот конкретный сценарий, но не получить доступ к ресурсу иначе. Создайте названную группу juniors и помещенный эти пользователи в эту группу. (Вы не должны на самом деле создавать группу, но она делает управление легче.) Создают правило sudo, которое позволяет пользователям в группе juniors получить полномочия группы seniors, но только выполнять одну определенную программу — сценарий, который читает файл паролей. Выполненный visudo добавить эту строку к sudoers файл:

%juniors ALL = (:seniors) /path/to/script ""

Юниоры могут выполнить сценарий путем вызова sudo -g seniors /path/to/script. Сценарий будет затем работать с дополнительными полномочиями, присужденными группой seniors. Тем не менее, пользователь, который звонил sudo не сможет получить доступ к файлу паролей (если сценарий не является багги и может быть обманут для утечки его).

Обратите внимание снова, что sudo только полезен при необходимости в некоторых людях, чтобы смочь получить доступ к ресурсу, не зная пароля. Это ничего не сделает для Вас, если все, что Вы хотите, должно ограничить доступ к паролю определенным пользователям и не позволить кому-либо еще получать доступ к ресурсу.

1
27.01.2020, 21:55

Спасибо ответившим. Конечный ответ, который я реализовал, таков... Я нашел в другом месте на этом сайте подпрограмму для сравнения паролей с /etc/shadow.

Поскольку я использую графический интерфейс, я использую zenity для запроса пароля. Человек на RPi не знает свой пароль из-за автологина. После ввода пароля он преобразуется в хэш с использованием соли из учетной записи пользователя и сравнивается сгенерированный хеш и исходный хэш. Если они совпадают, то запускается терминальная программа.

Если нажать кнопку отмены zenity или ввести неверный пароль, ничего не происходит.

Для запуска скрипта, которому нужны разрешения для grep файла /etc/shadow, у меня есть запись в /etc/sudoers.d/myfile = UserA ALL= (ALL )NOPASSWD :/ opt/myFiles/startTerminal.sh

Скрипт:

    USERNAME=UserA
    PASSWD=$(zenity --forms --title=" " \
        --text="Enter Password" \
        --add-password="" )

    if [[ $? -eq 0 ]]; then
        export PASSWD
        ORIGPASS=`grep -w "$USERNAME" /etc/shadow | cut -d: -f2`
        export ALGO=`echo $ORIGPASS | cut -d'$' -f2`
        export SALT=`echo $ORIGPASS | cut -d'$' -f3`
        GENPASS=$(perl -le 'print crypt("$ENV{PASSWD}","\$$ENV{ALGO}\$$ENV{SALT}\$")')
        if [ "$GENPASS" == "$ORIGPASS" ]; then
            /usr/bin/lxterminal &
            exit 0
        fi
    fi
0
27.01.2020, 21:55

Теги

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