Вот мой источник:
#!/bin/bash
echo "Running script to free general cached memory!"
echo "";
echo "Script must be run as root!";
echo "";
echo "Clearing swap!";
swapoff -a && swapon -a;
echo "";
echo "Clear inodes and page file!";
echo 1 > /proc/sys/vm/drop_caches;
echo "";
Он очищает кеши и прочее и повторяет, что его нужно запускать от имени пользователя root в терминале. Я просто хочу, чтобы скрипт прекратил работу, если обнаружит, что он не выполняется от имени пользователя root.
Пример:
"Running script to free general cached memory!"
"Warning: script must be run as root or with elevated privileges!"
"Error: script not running as root or with sudo! Exiting..."
Если запустить с повышенными привилегиями, он будет работать как обычно. Есть идеи? Благодарность!
shell-script
root
М. Кнеппер
источник
источник
root
префикс префикса всех команд, которые должны выполняться, какroot
сsudo
.Ответы:
Пользователь root имеет UID 0 (независимо от имени учетной записи «root»). Если возвращаемый эффективный UID
id -u
не равен нулю, пользователь не выполняет сценарий с привилегиями root. Используетсяid -ru
для проверки реального идентификатора (UID пользователя, вызывающего скрипт).Не используйте
$EUID
в скрипте, поскольку это может быть изменено непривилегированным пользователем:Если пользователь сделал это, это, очевидно, не приведет к повышению привилегий, но может привести к тому, что команды в сценарии не смогут выполнить то, что они должны делать, и файлы будут созданы с неправильным владельцем и т. Д.
источник
/bin/id -u
выдает/bin/id: illegal option -- u
Usage: id [-ap] [user]
/usr/xpg4/bin
раннем этапе$PATH
.-u
опцияid
не является универсальной, и поэтому это решение универсально только с предупреждением о том, что версия POSIXid
должна встречаться первой в вашей переменной PATH.$PATH
в верхней части сценария так, чтобы/usr/xpg4/bin
он был раньше/bin
. Если вы настаиваете на использовании не POSIXid
, то, очевидно, вам придется придумать более портативное решение.PATH=$( getconf PATH )
или установить какой-либо другой явный путь по умолчанию, или использовать явный путь для вызоваid
.Я думаю, что вы хотите скорее проверить, что у вас есть привилегии суперпользователя, то есть, что ваш эффективный идентификатор пользователя равен 0.
zsh
иbash
сделайте это доступным в$EUID
переменной, так что вы можете сделать:С любыми POSIX-подобными оболочками вы можете использовать
id
стандартную команду:Обратите внимание, что все
id -un
илиwhoami
или$USERNAME
переменная inzsh
получат первое имя пользователя для uid. В системах, в которых есть другие пользователи с идентификатором 0, это может не произойти,root
даже если процесс является потомком того, который был аутентифицирован какroot
.$USER
будет , как правило , дают вам пользователю , что проверка подлинности, но полагаться на него довольно хрупкими. Это не задаются оболочкой, но, как правило , устанавливается командой проверки подлинности (напримерlogin
,su
(на системах GNU / Linux, не обязательно другие),sudo
,sshd
(одного из OpenSSH , по крайней мере) ...). Хотя это не всегда (изменение uid не устанавливает эту переменную автоматически, это должно быть сделано явно приложением, меняющим uid), и это также могло быть изменено каким-то другим процессом в происхождении оболочки.$LOGNAME
с тем же предупреждением более надежно, как указано в POSIX (первоначально из FIPS 151-2)источник
Вы можете использовать
$USER
илиwhoami
для проверки текущего пользователя.источник
3.2.4.2 Conditional Constructs
3.5.4 Command Substitution
id -u
с-n
опцией или без нее является альтернативой использованию whoami. Без -n и сравнение с нулем лучше соответствует тесту, которое фактически выполняет ядро. Все, что заботит ядро - это идентификатор, а не имя из файла паролей.$(id -u)
лучше. В некоторых (злонамеренных) случаях$USER
может быть неправильно.На самом деле вы хотите определить, есть ли у вас доступ для выполнения этих операций. Проверять, действительно ли вы root вместо этого, считается плохой практикой.
Если система настроена так, чтобы пользователь без полномочий root мог изменять кеш страниц подкачки и удаления, почему этот пользователь не должен запускать ваш скрипт?
Вместо этого вы можете просто попробовать выполнить операцию и выйти с полезным сообщением, если оно завершится неудачно:
источник
exit
после чего-то произошел сбой, в случае, если пользователь хочет сделать столько, сколько он может со своими текущими привилегиями. (Но для типичной системы, где все это требует root, выход будет более полезным / менее шумным.)