Как команда 'passwd' получает разрешения пользователя root?
Я сомневаюсь, что Вы собираетесь найти столь же интересный ответ относительно вопроса о тильде!
Я не был там, но.. похож на замещающий знак (...), который имеет смысл в контекстах как cd ../../../there. Кроме того, и особенно смотря на Вас olde клавиатура терминала от случая тильды, с этой целью нет многих имеющих право символов. Вы не должны смещаться для ., также. Это прекрасно.
То, что точечный префикс используется для скрытых файлов, могло бы быть другой причиной. Скрытые файлы не перечислены по умолчанию инструментами такой как ls, таким образом, ни один не чрезвычайно избыточное . и ... Избыточный в том смысле, что нет никакого смысла, рассматривая их наряду с другими файлами - они, конечно, полезны иначе.
Как оказалось, у меня может быть он назад... из Википедии:
Понятие, что имена файлов, которым предшествует a'.', должны быть скрыты, является результатом программной ошибки в первые годы Unix. Когда специальное предложение '.' и '..' записи каталога были добавлены к файловой системе, было решено, чтобы команда ls не отображала их. Однако ls программа была по ошибке записана для исключения любого файла чье имя, запущенное с a'.', а не только названных '.' файлов или '..'.
Это действительно оказывается полезным при программировании; так как система действительно включает. и.. в ответ на readdir() введите команды (и окружите шарики), игнорируя их, и скрытые файлы могут быть выполнены тот же путь.
Другое мнение о том значении использования находится в ссылке для кавычки Википедии. Конечно, целая история могла быть недостоверной..., немного трудно полагать, что, например, Dennis Ritchie, изображенный, просто проверив на первый символ, был бы хорошо.
Я не соглашаюсь с автором vis, было бы лучше поместить скрытые конфигурационные файлы в их собственный каталог, а не дать им универсальный префикс. Префикс намного более гибок, допуская директивы в дереве как .gitignore и .htaccess. Свидетель, что файлы того вида также появляются вместе при лексикографической сортировке - поэтому, возможно, это было нарочно, в конце концов.
passwd программа имеет setuid набор битов, с которым Вы видите ls -l:
-rwsr-xr-x 1 root root 39104 2009-12-06 05:35 /usr/bin/passwd
Это s (четвертый символ строки).
Все программы, которые имеют этот набор бита полномочий, выполненный как владелец той программы. В этом примере пользователь root (третье слово строки).
Эти setuid программы должны удостовериться, что они ничего не повреждают, так как каждый пользователь системы может выполнить их с эффективными полномочиями пользователя root. Вот почему можно только изменить собственный пароль. Linux и другие подобные операционные системы все еще безопасны, потому что авторы этих setuid программ проявляют большую заботу.
Посмотрите, например, suexec.c от веб-сервера Apache, который является популярной setuid программой. В том исходном коде существует необычно много комментариев.
В качестве дополнения к ответу Роланда Иллига, вполне возможно написать программу, которая, получив права root'а, различными способами повреждает системные файлы и/или компрометирует вашу систему.
Проблема в том, что просто пишет , но это не значит, что она автоматически запускается от имени root - ей нужно, чтобы ее владелец установил root, и тогда бит setuid, на который ссылается Роланд, должен быть установлен - и только root имеет на это право.
Вкратце: Да, каждый двоичный файл с установленным битом setuid, по крайней мере, потенциально представляет собой риск для безопасности. Использование недостатка в бинарном файле с множеством битов setuid для получения привилегий root является наиболее распространенным источником так называемых Privilege Escalation атак, и они, как правило, имеют большое значение, когда они происходят. Из-за этого, существует относительно немного программ, которые используют setuid, и те, которые существуют, как правило, находятся под пристальным вниманием.