Поскольку другие упомянули 3-й пример, который Вы включали, должен был работать. Как альтернатива Вы могли использовать find
удалить эти файлы также.
Принятие следующих демонстрационных данных.
$ touch "(afile)"{1..5}
$ ls -l
total 0
-rw-rw-r-- 1 saml saml 0 Oct 30 13:47 (afile)1
-rw-rw-r-- 1 saml saml 0 Oct 30 13:47 (afile)2
-rw-rw-r-- 1 saml saml 0 Oct 30 13:47 (afile)3
-rw-rw-r-- 1 saml saml 0 Oct 30 13:47 (afile)4
-rw-rw-r-- 1 saml saml 0 Oct 30 13:47 (afile)5
Теперь удалите использование файлов find
(принятие Вас имеет версию GNU find
):
$ find . -name "(*" -delete
$ ls -l
total 0
$
] Если я не ошибаюсь, есть небольшие различия между []su[
] и []sudo[
]:[
]su[
] позволяет изменять только идентификатор пользователя (например, стать суперпользователем).[]su[
] позволяет любому пользователю, который знает пароль другого пользователя, стать этим пользователем, и нет никакой возможности контролировать это. []sudo[
] позволяет выполнять команду от имени другого пользователя (включая root).[]sudo[
] контролируется файлом []/etc/sudoers[
].[]Я думаю, что первоначальной целью команды []sudo[
] является лучший контроль над тем, кто может выполнять команды с привилегиями root, а кто нет. Если у вас система с несколькими администраторами, то []sudo[
] позволяет выполнять команды от имени root без необходимости использования пароля root, что, с моей точки зрения, более безопасно. Во многих дистрибутивах []/etc/sudoers[
] позволяет управлять списком пользователей или групп, которые могут использовать []sudo[
].[
В использовании, да, sudo может полностью заменить su. Но есть много скриптов и программ, которые используют su
, так что нет никакого способа безопасно его удалить.
Во многих недовериях Linux не предустановлено sudo. Использование sudo в скрипте сделает его несовместимым с этими системами. Как упомянул Джерней в своем комментарии, su является частью стандарта Posix. Это означает, что при написании скрипта следует доверять тому, что при использовании
su
ваш сценарий будет запущен на всех Posix-совместимых операционных системах.
Здесь - ссылка.
sudo
закрывает любые файловые дескрипторы больше, чем > & 2
для вызываемых процессов автоматически - что может быть проблемой.
Вся суть sudoers
- это еще одна (возможно, ненужная) абстракция от проверенных и верных / etc / passwd
базовых прав пользователя / группы в стиле Unix схема и требует своего собственного управления.
Например, из man growisofs
:
При выполнении под
sudo (8) growisofs
отказывается запускаться. Это сделано по следующей причине. Естественноgrowisofs
должен получить доступ к набору данных для записи на DVD-носитель, либо косвенно, позволяяmkisofs
генерировать макет ISO9660 на лету, либо напрямую, если предварительно обработанное изображение должно быть записано. Выполняясь подsudo (8)
,growisofs
, эффективно предоставляетsudoers
доступ для чтения к любому файлу в файловой системе. Ситуация усугубляется тем, чтоgrowisofs
анализирует переменную среды$ MKISOFS
, чтобы определить альтернативный путь к исполняемому образуmkisofs
. Это означает, что выполнение подsudo (8)
,growisofs
фактически предоставляетsudoers
право выполнять программу по своему выбору с повышенными привилегиями. Если вы по какой-либо причине все еще считаете приведенное выше приемлемым и готовы принять последствия, то рассмотрите возможность запуска следующего сценария оболочки подsudo (8)
вместо реального двоичного файлаgrowisofs
.
#!/bin/ksh
unset SUDO_COMMAND
export MKISOFS=/path/to/trusted/mkisofs
exec growisofs "$@"
Но обратите внимание, что рекомендуемая альтернатива вышеупомянутому «обходному пути» на самом деле заключается в установке
growisofs
set-root-uid
, и в этом случае он потеряет привилегии до доступа к данным или выполненияmkisofs
, чтобы предотвратить несанкционированный доступ к данным.
По крайней мере su
фактически временно переключает пользователей и сохраняет разрешения в стиле Unix. sudo
, с другой стороны, превосходит пользователей. Тем не менее, если вы правильно справитесь с этим в / etc / sudoers
sudo
, вероятно, сможет полностью заменить su
во многих отношениях и сделать это удобно - с некоторыми минимальными затратами для безопасности, потому что su
представляет большинство тех же проблем безопасности, что и sudo
- и, возможно, несколько собственных. Я считаю отличным обсуждением этой темы.
Но почему бы просто не пропустить их обоих и ...
CTRL + ALT + Fn
login: root
Или ...
ssh root@localhost
Что бы ни случилось с root все равно?