Пример 11.2. Структура инода файловой системы ext2fs 4 страница

Авторизация

Иннокентий на кухне, он пьет молоко Таракана завидев во мраке На душе его чисто, светло и легко Он не хочет впускать Полтораки Б. Гребенщиков

Механизмы авторизации в различных ОС и прикладных системах различны, но их трудно назвать разнообразными. Два основных подхода к авторизации — это ACL (Access Control List, список управления доступом) или список контроля доступа и полномочия (capability).
Список контроля доступа ассоциируется с объектом или группой объектов и представлет собой таблицу, строки которой соответствуют учетным записям пользователей, а столбцы — отдельным операциям, которые можно осуществить над объектом. Перед выполнением операции система ищет идентификатор пользователя в таблице и проверяет, указана ли выполняемая операция в списке его прав.
Реализация списков управления доступом вполне прямолинейна и не представляет непреодолимых сложностей. Разработчики системы безопасности, впрочем, могут (и часто бывают вынуждены) предпринимать достаточно сложные меры для сокращения ACL, предлагая те или иные явные и неявные способы объединения пользователей и защищаемых объектов в группы.
Полномочие представляет собой абстрактный объект, наличие которого в контексте доступа задачи позволяет выполнять ту или иную операцию над защищаемым объектом или классом объектов, а отсутствие — соответственно,
не позволяет. При реализации такой системы разработчик должен гарантировать, что пользователь не сможет самостоятельно сформировать полномочие.
Например, полномочие может быть реализовано в виде ключа шифрования или электронной подписи. Невозможность формирования таких полномочий обеспечивается непомерными вычислительными затратами, которые нужны для подбора ключа.

Списки контроля доступа

— Что это?— вытянул шею Гмык, хмуро глядя на мои карты. — Но тут,же только. — Минутку, — вмешался игрок слева от него. — Сегодня вторник. Выходит, его единороги дикие. — Но в названии месяца есть "М"— вякнул еще кто-то. — Значит, его великан идет за половину номинальной стоимости! — Но у нас четное число игроков... — Вы все кое-что упускаете. Эта партия — сорок третья, а Скив сидит на стуле лицом к северу! Приняв за указание стоны и все заметнее вырисовывавшееся выражение отвращения на лицах, я сгреб банк. Р. Асприн

В общем случае совокупность всех ACL в системе представляет собой трехмерную матрицу, строки которой соответствуют пользователям, столбцы -операциям над объектами, а слои — самим объектам. С ростом количества объектов и пользователей в системе объем этой матрицы быстро растет, поэтому, как уже говорилось, разработчики реальных систем контроля доступа предпринимают те или иные меры для более компактного представления матрицы.
Хотя ухищрения для сокращения ACL дают определенный эффект, и в большинстве случаев список имеет всего лишь несколько записей (рис. 12.9), наложение ограничений на его размер часто считают неприемлемым или устанавливают такие ограничения весьма высокими, например в несколько тысяч записей. Это приводит к тому, что с файлом в ФС, поддерживающих списки контроля доступа, кроме основного массива данных, оказывается связан еще один массив, обычно уступающий в размерах основному, но, в принципе, способный достигать очень большого объема.
Впрочем, соответствующее усложнение файловой системы не так уж велико. Многие ФС позволяют хранить в дополнительных блоках данных не только записи ACL, но и другие сущности — расширенные атрибуты, ресурсную ветвь и т. д.

Рис. 12.9. Список контроля доступа

Есть три основных подхода, используемых для сокращения ACL.

• Использование прав по умолчанию
• Группирование пользователей и/или объектов
• Ограничение комбинаций прав, которыми пользователи и группы могут реально обладать

Права по умолчанию дают наибольший эффект тогда, когда большая часть прав большинства пользователей на большинство объектов одинакова. Чаще всего рекомендуют при установлении прав исходить из принципа "запрещено все, что не разрешено [явным образом]" — при последовательном его применении должно получаться, что большинство пользователей не имеет прав на подавляющую часть объектов в системе. Исходя из этого, в большинстве систем пользователи, явно или неявно не перечисленные в ACL объекта, не имеют на объект никаких прав. Многие системы также предоставляют специальную запись в ACL, соответствующую пользователям, которые не перечислены явно.
Объединение пользователей в группы представляет собой более универсальное средство, которое полезно не только для сокращения ACL, но и для других целей. Группа вводит дополнительный уровень косвенности (ACL ссылается на пользователя не прямо, а косвенно, через группу в систему установления прав и управления ими, и это дает дополнительную гибкость, полезную во многих практических случаях (рис. 12.10).

Рис. 12.10. Группы пользователей

Так, в большинстве случаев полномочиями наделяют человека не за то, что он такой хороший, а потому, что они нужны ему для выполнения служебных обязанностей. Изменение служебных обязанностей (постоянное, при переходе на другую должность, или временное, например, при замене заболевшего или ушедшего в отпуск сотрудника) сопровождается изменением прав, которыми пользователь должен обладать.
В этой ситуации целесообразно создать группу, соответствующую той или иной должности, и выдавать права на объекты этой группе. Назначение человека на должность сопровождается включением его в соответствующую группу, а снятие — исключением из нее. Без использования групп эти операции потребовати бы явной модификации ACL всех объектов, права на которые изменяются, что во многих случаях совершенно нерационально.
Группы яшшотся практически обязательным элементом систем упраатения правами на основе списков. Большинство систем предоставляет возможность создания вложенных групп (рис. 12.11). Ряд современных систем (Novell Netware 4..Y, Windows 2000, Solans 6) предоставляют также иерархические структуры БД учетных записей, почему-то называемые службами каталогов (NDS -Netware Directory Service в Netware, Active Directory в Windows, NIS+ - - Network Information Service в Solans). Впервые служба каталогов была реализована в сетевой ОС VINES (Virtual NEtwork Services) фирмы Banyan Systems в конце 80-х.

Рис. 12.11. Вложенные группы и структура организации

Иерархическая структура особенно удобна для больших организаций, потому что она не только обеспечивает "естественную" структуру вложенных групп, но и облегчает просмотр учетных записей и управление ими.
При активном использовании групп пользователей может возникнуть специфическая проблема: пользователь может состоять в нескольких группах и иметь собственную запись в ACL и, таким образом, получать права на объект несколькими путями (рис. 12.12). Строго говоря, проблемой это не является, важно лишь описать, что будет происходить с правами в этом случае. В различных системах используются почти все мыслимые варианты поведения.

Рис. 12.12. Получение прав из нескольких групп

Чаще всего права, полученные разными путями, просто складываются. Бывают системы, в которых отдельные права тем или иным образом ранжируются, и пользователь получает список прав, соответствующий той записи в ACL, которая содержит наивысшее право. Очень часто некоторые записи в ACL обладают особым статусом. Так, если человек имеет явную (соответствующую его пользовательскому идентификатору) запись в ACL, записанные в ней права оказываются "сильнее" всех прав, которые он получает как член группы. Запись с правами по умолчанию часто рассматривается как более "слабая", чем явные и групповые записи, и при наличии у пользователя прав, полученных из записей по умолчанию, вообще игнорируется.
Каждое из этих правил по отдельности обычно Преследует цель облегчить формирование списков, предоставляющих требуемые комбинации прав, но в результате полное описание семантики ACL многих распространенных ОС напоминает вынесенные в эпиграф фрагменты правил игры в "драконий покер".
Группирование объектов используется несколько реже, но также является мощным средством управления правами и сокращения общего объема ACL в системе. Для файловых систем естественным средством группирования является иерархия каталогов.

Наследование прав на файлы в Novell Netware
По-видимому, наибольшей сложности группирование объектов достигло в системе Novell Netware. Рассмотрим схему установления прав на файлы в этой ОС.
Запись файлового ACL в Netware представляет собой битовую маску, значения разрядов которой перечислены в табл. 12.1. Видно, что некоторые из прав имеют смысл только для файлов, а некоторые — только для каталогов.
Каталоги и файлы в этой системе наследуют права доступа от родительских каталогов. Если пользователь или группа не перечислены явно в ACL объекта, их эффективные права будут определяться записями в ACL родительских каталогов (рис. 12.13). Если пользователь перечислен в ACL родительского и дочернего каталогов, его эффективные права будут равны сумме прав, указанных в обеих записях. Таким образом, по мере спуска по дереву каталогов, эффективные права могут только возрастать.

Рис. 12.13. Наследование прав на каталоги в Novell Netware (обозначения прав соответствуют табл. 12.1)

При этом пользователь не обязан иметь права на каталог, чтобы видеть его файлы и подкаталоги. Поэтому система управления доступом Netware предполагает выдачу прав как можно ближе по дереву каталогов к тем файлам, права на которые необходимы. Права на корневые каталоги томов обычно выдаются только администратору системы.
В случае если все-таки потребуется изменить принцип расширения прав по мере спуска по дереву, каталоги и файлы, кроме ACL, имеют дополнительный атрибут, называемый IRF (Inherited Rights Filter— фильтр наследуемых прав). Этот атрибут представляет собой битовую маску, биты которой (кроме бита S — он не может быть отфильтрован) соответствуют битам записи ACL (см. табл. 12.1). Установка бита в этой маске приводит к блокировке наследования соответствующего права (рис. 12.14).

Рис. 12.14. Фильтр наследуемых прав в Novell Netware

Запрет на фильтрацию права супервизора обусловлен тем, что его включение по ошибке приведет к потере администратором прав на эту иерархию. Избавиться от такого поддерева можно было бы только переразметкой тома.
В пользовательской базе данных, которая, начиная с Netware 4.x, также имеет иерархическую структуру, и наследование, блокирование супервизорских прав разрешено, поэтому можно по ошибке "даровать суверенитет" ветви дерева (рис. 12.15). Это одна из распространенных ошибок начинающих администраторов. В административных утилитах Netware 4.11 даже была введена специальная проверка, не позволяющая отфильтровать право супервизора, если ни у кого нет явно выданных супервизорских прав на соответствующий контейнер или объект.

Рис. 12.15. Дарование суверенитета ветви дерева каталогов

Таблица 12.1. Права доступа к файлу в Novell Netware 3.x и выше

Бит	Обозначение	Описание
S	Supervisor	Право осуществлять любые операции над файлом или каталогом
А	Access	Право модифицировать ACL файла или каталога
R	Read	Право читать файл
С	Create	Право создавать файлы в каталоге
W	Write	Право записи в файл
Е	Erase	Право удалять файл или каталог
М	Modify	Право изменять атрибуты файла или каталога
F	Find	Право на поиск файлов в каталоге

Альтернативой этим хитростям является третий из упомянутых путей -ограничение комбинаций прав, которые реально могут быть выданы. С одним из примеров такого ограничения мы сталкивались в разд. Сегменты, страницы и системные вызовы: диспетчер памяти VAX имеет четыре уровня привилегий, каждый из которых может иметь право чтения и записи в страницу памяти. Все возможные комбинации прав в этих условиях кодируются 8-ю битами, но наложение требования о том, что каждый более высокий уровень обязан иметь хотя бы те же права, что и более низкие, позволяет нам обойтись 15-ю допустимыми комбинациями и 4-мя битами для их кодирования.
При разработке такой системы мы сталкиваемся с нетривиальной задачей: нам нужно выработать такие ограничения, которые не только обеспечивали бы компактное представление ACL, но и позволяли так или иначе реализовать комбинации прав, необходимые для практической эксплуатации вычислительных систем.
Замечательным примером ограниченного ACL, структура которого выдержала 30-летнюю проверку практикой, является модель безопасности в системах семейства Unix.

Авторизация в Unix
В этих системах ACL состоит ровно из трех записей (рис. 12.16).
Права хозяина файла (пользователя)
Права группы
Права по умолчанию

Рис. 12.16. Установление прав в системах семейства Unix

Как правило, права хозяина выше прав группы, а права группы выше прав по умолчанию, но это не является обязательным требованием и никем специально не проверяется. Пользователь может принадлежать к нескольким группам одновременно, файл всегда принадлежит только одной группе.
Бывают три права: чтения, записи и исполнения. Для каталога право исполнения означает право на открытие файлов в этом каталоге. Каждое из прав обозначается битом в маске прав доступа, т. е. все три группы прав представляются девятью битами или тремя восьмеричными цифрами.
Права на удаление или переименование файла не существует; вообще, в Unix не определена операция удаления файла как таковая, а существует лишь операция удаления имени unlink. Это связано с тем, что файл в Unix может иметь несколько имен, и собственно удаление происходит только при уничтожении последнего имени (подробнее см. главу 11). Для удаления, изменения или создания нового имени файла достаточно иметь право записи в каталог, в котором это имя содержится.
Удаление файлов из каталога, в действительности, можно в определенных пределах контролировать: установка дополнительного бита (маска прав содержит не девять, а двенадцать бит, с семантикой еще двух из них мы познакомимся в разд. Изменение идентификатора пользователя) запрещает удаление из каталога чужих файлов. Обладатель права записи в такой каталог может создавать в нем файлы и удалять их, но только до тех пор, пока они принадлежат ему.
Кроме прав, перечисленных в маске, хозяину файла разрешается изменять права на файл: модифицировать маску прав и передавать файл другой группе и, если это необходимо, другому пользователю (в системах с дисковыми квотами передавать файлы обычно запрещают).
Еще один обладатель прав на файл, не указанный явно в его ACL, — это администратор системы, пользователь с идентификатором, равным 0. Этот пользователь традиционно имеет символическое имя root. Полномочия его по отношению к файлам, другим объектам и системе в целом правильнее описать даже не как обладание всеми правами, а как возможность делать с представленными в системе объектами что угодно, не обращая внимания на права.
В традиционных системах семейства Unix все глобальные объекты — внешние устройства и именованные программные каналы — являются файлами (точнее, имеют имена в файловой системе) и управление доступом к ним выполняется файловым механизмом. В современных версиях Unix адресные пространства исполняющихся процессов также доступны как файлы в специальной файловой (или псевдофайловой, если угодно) системе ргос. Файлы в этой ФС могут быть использованы, например, отладчиками для доступа к коду и данным отлаживаемой программы (рис. 12.17). Управление таким доступом также осуществляется стандартным файловым механизмом.
В Unix System V появились объекты, не являющиеся файлами и идентифицируемые численными ключами доступа вместо имен, а именно средства межпроцессного взаимодействия: это семафоры, очереди сообщений и сегменты разделяемой памяти. Каждый такой объект имеет маску прав доступа, аналогичную файловой, и доступ к нему контролируется точно так же, как и к файлам.

Основное преимущество этого подхода состоит в его простоте. Фактически это наиболее простая из систем привилегий, пригодная для практического применения. Иными словами, более простые и ограниченные системы установления привилегий, по-видимому, непригодны вообще.

Рис. 12.17. Дерево каталогов Unix

Многолетний опыт эксплуатации систем, использующих эту модель, показывает, что она вполне адекватна подавляющему большинству реальных ситуаций. Впрочем, ряд современных файловых систем в ОС семейства Unix предоставляет произвольного вида списки для управления доступом.

Полномочия

Ты пришли ко мне утром, ты cела на кровать Ты спросила, есть ли у меня разрешение дышать И действителен ли мой пропуск Чтобы выйти в кино Б. Гребенщиков

В чистом виде модель авторизации на основе полномочий реализована в системах Burroughs и Intel 432, которые подробнее рассматриваются в разд. Сегменты, страницы и системные вызовы и Взаимно недоверяющие подсистемы. Полномочия доступа к сегментам единого адресного пространства в этих системах реализованы в виде полей селектора сегмента или мандатов, а невозможность самостоятельной их генерации пользователем обеспечена тэговой архитектурой и запретом арифметических операций над сегментной частью указателя.
Системы с моделями безопасности, основанные на одних лишь полномочиях, не имели коммерческого успеха. Однако концепция полномочий распространена гораздо шире, чем это принято думать. Так, реализация модели безопасности на основе ACL возможна лишь постольку, поскольку системные модули имеют полномочия делать что угодно, не обращаясь ни к каким ACL (в частности, и полномочия выполнять перечисленные в ACL операции), а пользовательский код таких полномочий не имеет. В силу этого, пользователь может выполнять необходимые ему операции лишь посредством обращения к системным модулям.
Только в этих условиях проверка ACL перед входом в системный модуль имеет смысл — если бы пользователь мог бы выполнить операцию сам или вызывать системные подпрограммы без ограничений, обход любого ACL выполнялся бы очевидным образом.
В частности, поэтому в системах с открытой памятью невозможны сколько-нибудь эффективные средства управления доступом: пользователь имеет возможность выполнять любые операции самостоятельно, а при использовании криптографической защиты может похитить ключ или модифицировать алгоритм шифрования.
Типичная практически используемая архитектура управления доступом предоставляет пользователю и системному администратору управление правами в форме списков контроля доступа и содержит один или несколько простых типов полномочий, чтобы предотвратить доступ в обход этих списков. Простейшей структурой таких полномочий является разделение пользовательского и системного режимов работы процессора и исполнение всего не пользующегося доверием кода в пользовательском режиме.
Системный режим процессора является полномочием или, во всяком случае, может применяться в качестве такового: обладание им позволяет выполнять операции, недопустимые в пользовательском режиме, и этот режим не может произвольно устанавливаться. Он позволяет реализовать не только ACL, но и дополнительные полномочия: пользователь не имеет доступа в системное адресное пространство, поэтому система может рассматривать те или иные атрибуты дескриптора пользовательского процесса как полномочия (рис. 12.18).
Идентификатор пользователя, устанавливаемый при аутентификации и хранящийся в дескрипторе процесса в адресном пространстве ядра, также может рассматриваться как полномочие. Для того чтобы этот идентификатор действительно можно было использовать таким образом, необходимо ввести весьма жесткие ограничения на то, кто и каким образом может производить аутентификацию.
Два подхода к решению этой задачи — это осуществление аутентификации модулями ядра и введение специального идентификатора пользователя (или специального типа процессов).

Рис. 12.18. Хранение полномочий в системном адресном пространстве

Включение средств аутентификации в ядро кажется весьма привлекательным: мы можем быть уверены, что никто не получит чужие полномочия, иначе как пройдя штатную процедуру проверки идентичности. С другой стороны, каждый процесс, считающий, что ему следует произвести смену идентичности (например, сервер, исполняющий запрос от имени конкретного пользователя) может запросить у пользователя имя и пароль и переау-тентифицироваться без каких-либо трудностей.
Проблема при таком подходе состоит в том, что мц ограничиваем используемые в системе способы аутентификации и форматы пользовательской базы данных.
Разработка модулей, реализующих альтернативные способы аутентификации (например, применяющих папиллярный детектор или сканер глазного дна вместо запроса пароля) или нестандартные способы хранения списков пользователей резко усложняются — теперь это должны быть не простые разделяемые библиотеки, а модули ядра.
Осуществление аутентификации в пользовательском режиме требует введения специального [псевдо]пользователя, которому разрешено становиться другими пользователями (или, говоря точнее, приобретать их идентичность) или специального типа процессов, которые могут делать это. Привилегия входить в систему и запускать процессы с таким идентификатором должна жестко контролироваться: ведь обладатель таких полномочий может стать кем угодно и, таким образом, выполнять любое действие, которое кому-либо разрешено.

Аутентификация в Unix
В системах семейства Unix процессы с эффективным пользовательским идентификатором, равным 0, имеют право исполнять системные вызовы setuid и setgid и, таким образом, становиться другими пользователями. Другие пользователи не имеют такой возможности, поэтому все процессы, в той или иной форме, осуществляющие аутентификацию и смену идентичности, как с применением стандартных системных средств (файлов /etc/passwd и /etc/shadow в старых системах и разделяемых библиотек РАМ в современных), так и самостоятельно, обязаны исполняться от имени этого пользователя.
Поскольку пользователь с идентификатором 0 (root) может приобретать идентичность других пользователей, он, как уже говорилось, фактически обладает всеми правами, которые есть у кого бы то ни было другого в системе. Признав этот факт, разработчики Unix явным образом дали пользователю root вообще все права, в том числе и такие, которых не имеет никто другой.
Мы уже отмечали в разд. Списки контроля доступа, что root может производить любые операции над файлами, безотносительно к тому, кому они принадлежат и какие права у них установлены, root также имеет возможность перезагружать систему, в ОС с динамической загрузкой модулей ядра — загружать, выгружать и перенастраивать эти модули, запускать процессы с классом планирования реального времени, посылать сигналы чужим процессам (простые смертные могут это делать только со своими процессами) и выполнять множество других операций, недоступных другим пользователям. Фактически, все действия, так или иначе затрагивающие систему в целом, являются исключительной прерогативой пользователя root [Хевиленд/Грэй/Салама 2000].
В небольших и средних организациях это не представляет проблемы, потому что все функции, требующие привилегий root, — резервное копирование и восстановление данных, регистрация пользователей и управление их полномочиями и собственно настройка системы исполняются одним человеком или командой более или менее взаимозаменяемых людей, должность которых и называется системный администратор.
В крупных организациях перечисленные функции могут исполняться разными людьми: администратором учетных записей (account manager), администратором данных (data administrator) (или администратором резервных копий) и собственно системным администратором (рис. 12.19).
Механизм, предоставляемый системами семейства Unix, который может быть использован для реализации такого разделения полномочий, будет обсуждаться в разд. Изменение идентификатора пользователя. Несколько забегая вперед, скажем, что решение состоит в том, чтобы разрешить администраторам учетных записей и данных запуск с полномочиями root только определенных программ (например, утилит управления пользователями и резервного копирования), но не запуск произвольных программ и не выполнение произвольных действий.

Рис. 12.19. Разделение полномочий администраторов системы

Многие поставщики коммерческих Unix-систем предоставляют комплектации ОС с повышенным уровнем безопасности, содержащие средства для упомянутого выше разделения полномочий между администраторами. Аутентификация для полноправного входа в систему с именем root в таких системах обычно предполагает ввод нескольких паролей, которые, по замыслу, должны быть известны разным людям, так что для выполнения всех действий, требующих полных административных полномочий, необходимо собирать комиссию., Как правило, такая комиссия состоит из одного или нескольких технических специалистов и одного или нескольких представителей руководства компании.
ОС в такой комплектации применяются на центральных серверах крупных компаний, в банковских системах и других приложениях, где ведется работа с ценными и высоко конфиденциальными данными.

Многие ОС предоставляют и полномочия доступа к отдельным объектам — для того, чтобы не проверять ACL объекта при каждой операции. Так, в системах семейства Unix права доступа к файлам проверяются только в момент открытия. При открытии необходимо указать желаемый режим доступа к файлу: только чтение, только запись или чтение/запись. После этого пользователь получает "ручку" - - индекс дескриптора открытого файла в системных таблицах.
Ручка представляет собой целое число и не имеет смысла в отрыве от соответствующего ей дескриптора, зато дескриптор является типичным полномочием: он недоступен пользовательскому коду непосредственно, потому что находится в системном адресном пространстве. Дескриптор может быть сформирован только системным вызовом open и допускает только те операции над файлом, которые были запрошены при открытии. Во время выполнения операций проверка прав доступа не производится (хотя, конечно, проверяется их физическая выполнимость: наличие места на устройстве и т. д.), так что если мы изменим ACL файла, это никакие повлияет на права процессов, открывших файл до этой модификации.

Изменение идентификатора пользователя

В некоторых случаях у разработчиков приложений или ОС возникает потребность или, во всяком случае, желание разрешить контролируемую смену идентичности для исполнения одной операции или группы тесно связанных операций над данными. Требование контролируемости означает, что нельзя разрешать пользователю свободное выполнение таких операций: например, в системе документооборота пользователю может быть разрешено поставить под документом подпись, что он с ним ознакомился, но при этом не дано права изменять содержание документа или удалять ранее поставленную подпись. Если предоставляемый системой список прав на документ либо позволяет редактирование документа целиком, либо опять-таки целиком запрещает его редактирование, то мы сталкиваемся с неразрешимой проблемой.

Авторизация доступа к полям документа в Notes
Программный комплекс Lotus Notes, широко признанный как лучшая основа для реализации систем документооборота, позволяет устанавливать права на отдельные поля или группы полей документа, а стандартная техника реализации вышеприведенных требований состоит в том, чтобы сначала предоставить пользователю право записи в поле, где должна быть подпись, а потом — после подписания — это право тут же снять. Впрочем, при реализации сложных циклов документооборота, включающих много взаимосвязанных документов, нередко возникают ситуации, неразрешимые с помощью только этих средств [Керн/Линд 2000].

Можно привести и другой пример, более тесно связанный с темой книги: для изменения информации о пользователе необходим доступ для записи в соответствующую базу данных, но не во всю, а только в определенную запись. Вполне естественно и даже необходимо дать пользователю возможность менять пароль, не обращаясь к администратору. С другой стороны, совершенно недопустимо, чтобы один пользователь, не являясь администратором учетных записей, мог сменить пароль другому.
Одним из решений было бы хранение пароля для каждого из пользователей в отдельном файле, но это во многих отношениях неудобно. Другое решение может состоять в использовании модели клиент-сервер с процессом-сервером, исполняющимся с привилегиями администратора, который является единственным средством доступа к паролям. Например, в Win32 весь доступ к пользовательской базе данных осуществляется через системные вызовы, т. е. функции процесса-сервера исполняет само ядро системы.
В системах семейства Unix для этой цели был предложен оригинальный механизм, известный как setuid (setting of user id - установка [эффективного] идентификатора пользователя). По легенде, идея этого механизма возникла именно при решении задачи о том, как же пользователи смогут менять свои пароли, если их хэши будут храниться в одном файле.