Причина, по которой это разрешено сегодня, заключается просто в том, что система не препятствует этому.
Если бы это изменилось, то это сломало бы те системы, где администраторы использовали эту функцию (см. Пример Terdon). Так что это никогда не менялось, и я не думаю, что это когда-либо изменится.
Первоначально были только файлы passwd и group, и они служили своей цели. не было команды adduser , addgroup , файлы редактировались пользователем root с помощью vi или ed.
Было несколько причуд!
Чтобы запомнить следующий идентификатор пользователя для использования, для администраторов было свойственно иметь специального пользователя в качестве последней строки, которая имела имя пользователя !
(потому что это !
было неверное имя пользователя), и эта запись использовалась для хранения следующего Идентификатор пользователя. Грубый, я признаю, но это сработало! Так зачем ломать кишку, делая ее более сложной, сродни гибкому развитию сегодня.
Были известные недостатки. Главное, что он должен быть читаемым для всего мира, чтобы такие утилиты ls
могли отображаться user-id => name
. Это означало, что любой мог видеть зашифрованный пароль каждого, всех пользователей и идентификаторов в системе.
Некоторые системы Unix начали вводить пару сценариев оболочки adduser
addgroup
, часто они игнорировались, потому что они были несовместимы между Unix, поэтому большинство людей просто продолжили ручное редактирование.
Прошло довольно много лет, прежде чем shadow
файл паролей был изобретен, это обеспечило немного большую безопасность, скрывая зашифрованные пароли. Опять же, была добавлена достаточная сложность, но она все еще была довольно грубой и простой Утилиты useradd
и groupadd
были введены, которые хранятся shadow
и shadow-
обновляются. Начнем с того, что это часто были простые оболочки сценариев оболочки вокруг проприетарных утилит adduser / addgroup . Опять же, этого было достаточно, чтобы продолжать идти.
Сети компьютеров росли, люди работали над несколькими за раз, чтобы выполнить работу, поэтому администрирование passwd/group
файлов становилось кошмаром, особенно с NFS, поэтому появились «Желтые страницы», также известные как NIS, для облегчения бремени.
Теперь стало очевидно, что нужно что-то более гибкое, и был изобретен PAM. Поэтому, если вы действительно искушены и хотели бы иметь централизованную, безопасную систему с уникальным идентификатором и всеми системами аутентификации, вы должны обратиться к центральному серверу для аутентификации, например, к серверу Radius, серверу LDAP или Active Directory.
Мир вырос. Но файлы passwd / group / shadow все еще оставались для нас меньших пользователей / разработчиков / лабораторий. Нам все еще не требовались все навороты. Я полагаю, что философия к настоящему времени немного изменилась: «Если вы собираетесь сделать это лучше, вы не будете его использовать вообще» , так что не беспокойтесь об этом.
Вот почему я не думаю, что простой файл passwd когда-либо изменится. Больше нет никакого смысла, и это просто замечательно для тех Raspberry Pi за 30 фунтов стерлингов с 2, 3, 3 наблюдателями температуры пользователя и твиттерами. Хорошо, вам просто нужно быть немного осторожнее с вашими идентификаторами пользователей, если вы хотите, чтобы они были уникальными, и ничто не мешает энтузиасту обернуть useradd в скрипт, который сначала выбирает следующий уникальный идентификатор из базы данных (файла), чтобы установить уникальный идентификатор, если это то, что вы хотите. В конце концов, это открытый исходный код.