Да, most замечательно справляется с раскраской, но по функционалу и, по моим субъективным ощущениям, удобству уступает less. В частности, как я написал, сразу появился дискомфорт из-за отсутствия переходов в начало и в конец страницы по клавишам Home и End соответственно.
И да, и нет. :) Пароля нет, но учетная запись блокирована.
man passwd:
-l, --lock
Lock the password of the named account. This option disables a
password by changing it to a value which matches no possible
encrypted value (it adds a ´!´ at the beginning of the password).
Работа от имени обычного пользователя и выполнение административных действий с использованием sudo — распространенная практика, которая становится только шире. Помимо этого, вход пользователя root по SSH как правило блокируется.
Все верно, но если быть до конца точным, то в том же ubuntu учетная запись root «из коробки» имеет не просто случайный пароль но в добавок и заблокирована (а-ля passwd -l). :)
Vim используется не только для правки конфигурационных файлов и административных скриптов, но многими также и при программировании. Я хочу сказать, что чаще он все же должен работать от обычного пользователя. ;)
Были еще такие варианты:
— пересохранение во временный файл;
— копирование в буфер (если консоль позволяла), закрытие без сохранения изменений, переоткрытие с нужными правами (от нужного пользователя) и вставка из буфера.
=)
Приведенный трюк по удалению одного файла (если права позволяют) сработает, а вот, например, ключи «rf» rm уже не получит, как верно заметил coldflame.
С другой стороны, #!/bin/rm в качестве первой строки это дрогуй очень распространенный трюк, спомощью которого делаются «одноразовые» сценарии, которые сразу самоуничтожаются после выполнения, что порой очень полезно.
Last but not least, если у злонамеренного пользователя есть доступ к системе во время отсутствия хозяина, то это грубое нарушение базовых правил безопасности и, соглашаясь с sergicus, следует отметить, что редактирование подобного исполняемого файла далеко не самое ужасное из возможных вариантов развития событий. :) Блокировать экран нужно, отходя от рабочего места, что ли… %) Приведенный способ должен облегчить жизнь в первую очередь хозяину, а об упомянутом случае должна заботиться политика безопасности.
Также в случае исключительно локального применения memcached полезным окажется отредактировать параметры запуска (в файле /etc/init.d/memcached) так, чтобы прослушивался только loopback-интерфейс:
Сегодня заметил, что описанное использование ssh-proxy (nc based) приводит к порождению процессов nc на транзитной машине без их уничтожения по окончании сеанса работы.
man passwd:
cat /etc/shadow | grep root
— пересохранение во временный файл;
— копирование в буфер (если консоль позволяла), закрытие без сохранения изменений, переоткрытие с нужными правами (от нужного пользователя) и вставка из буфера.
=)
С другой стороны, #!/bin/rm в качестве первой строки это дрогуй очень распространенный трюк, спомощью которого делаются «одноразовые» сценарии, которые сразу самоуничтожаются после выполнения, что порой очень полезно.
Last but not least, если у злонамеренного пользователя есть доступ к системе во время отсутствия хозяина, то это грубое нарушение базовых правил безопасности и, соглашаясь с sergicus, следует отметить, что редактирование подобного исполняемого файла далеко не самое ужасное из возможных вариантов развития событий. :) Блокировать экран нужно, отходя от рабочего места, что ли… %) Приведенный способ должен облегчить жизнь в первую очередь хозяину, а об упомянутом случае должна заботиться политика безопасности.