С wmctrl:
wmctrl -a Stardict
С xdotool:
xdotool windowactivate $(xdotool search --class Stardict)
Я использовал Stardict
для класса окна проверьте, что это правильно с xprop
(выполненный xprop
в терминале затем нажимают на непредставленное в виде значка окно Stardict и проверяют WM_CLASS
строка).
Sudo мог бы быть способом пойти.
Имейте своего владельца сценария и исполняемый файл определенным пользователем и не предоставляйте доступ от других пользователей, 700 полномочий, например.
Во-вторых, отредактируйте свое sudoers использование файла visudo
и добавьте строку как следующее:
%your_group ALL=path_to_script/script
Все пользователи, которые способны к запущению скрипта, должны быть добавлены к your_group.
Так, кто бы ни не часть your_group, не сможет запустить скрипт. Альтернатива может быть для Вас к определенному просто именем пользователя.
username ALL=path_to_script/script
Необходимо удостовериться, что пароль только читаем авторизованными пользователями. Не храните пароль в сценарии, храните его в отдельном файле, который Вы читаете из сценария. Намного легче управлять полномочиями этот путь. При хранении учетных данных в сценарии трудно быть уверенным, где они закончат: они могут быть непреднамеренно скопированы вокруг, они должны быть введены в управление версиями и т.д.
Разделение учетных данных из сценария обладает вторым и возможно более важным преимуществом. Это разделяет “разрешение выполнить сценарий” из “разрешения получить доступ к ресурсу”, который хорош, потому что Вы действительно не пытаетесь препятствовать тому, чтобы люди выполнили Ваш сценарий, Вы пытаетесь препятствовать тому, чтобы люди получили доступ к ресурсу. Так устанавливает полномочия на файле паролей соответственно, и Вы будете установлены.
Простой способ управлять полномочиями состоит в том, чтобы создать группу и поместить пользователей, которым разрешают получить доступ к ресурсу в той группе. Давайте назовем группу 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 только полезен при необходимости в некоторых людях, чтобы смочь получить доступ к ресурсу, не зная пароля. Это ничего не сделает для Вас, если все, что Вы хотите, должно ограничить доступ к паролю определенным пользователям и не позволить кому-либо еще получать доступ к ресурсу.
Спасибо ответившим. Конечный ответ, который я реализовал, таков... Я нашел в другом месте на этом сайте подпрограмму для сравнения паролей с /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
/etc/sudoers
зарегистрируйте непосредственно, используйте инструментvisudo
сделать редактирования. – slm♦ 09.07.2013, 10:22visudo
отредактировать/etc/sudoers
.sudoedit
не проверит синтаксис файла. спасибо – 09.07.2013, 14:27