Повне ім'я користувача скорочено до GECOS тому, що в незапам'ятні часи хтось із розробників UNIX використовував сервер друку під управлінням General Electric Comprehensive Operating System. В єдиному полі. вміст якого не використовується UNIX. довелося зберігати пароль для передачі документів на друк. Інформація в / etc / passwd - несекретна, цей файл доступний для читання будь-якому користувачеві.
Виникає питання: а де зберігається системний пароль користувача? Відповідь: ніде. UNIX не зберігає паролі ні відкритим текстом, ні в зашифрованому вигляді. Замість пароля зберігається ключ (hash) - послідовність символів, що отримується з пароля невідновні шифруванням. Довгий час цей ключ зберігали в другому полі / etc / passwd. Кожному паролю однозначно відповідає ключ. і щоб перевірити, чи правильно користувач його ввів, досить з введеного виготовити другий ключ і порівняти його з відповідним полем в / etc / passwd. Обчислити пароль. маючи один тільки ключ. не можна; все, що залишається передбачуваному зловмисникові, - це спробувати його підібрати (придумувати варіанти пароля і порівнювати ключі).
По-хорошому, саме ключ нікому, крім самої системи, знати і не треба. До того ж, якщо мати у своєму розпорядженні деякими знаннями про структуру пароля (день народження, вміст GECOS, ім'я улюбленої кішки і т. П.), Підібрати його може бути дуже просто. Можна скористатися досить потужним комп'ютером (наприклад, обчислювальним кластером) і просто підібрати цей пароль "в лоб". Щоб виключити принципову можливість підбору, в сучасних версіях FreeBSD і Linux ключ з файлу / etc / passwd видалили в файл. недоступний для читання нікому, крім користувача root. Туди ж прийнято записувати розширення стандартного passwd. зразок термінів дії пароля і облікового запису або класу користувача. У системах гнізда BSD цей файл називається /etc/master.passwd, він містить дійсно всю інформацію про користувача. У багатьох інших системах використовується схема з / etc / shadow. в якому міститься тільки додаткова інформація.
Суперкористувач. підміна ідентифікатора
Користувач root (він же "привілейований") має нульові UID і GID і грає роль довіреної суб'єкта UNIX. Це означає, що він не підкоряється законам, які керують правами доступу. і може на свій розсуд ці права змінювати. Більшість налаштувань системи доступні для запису тільки суперкористувачеві (навіть якщо файл має права доступу 0444, root все одно може в нього писати). Взагалі, root - страшна людина! Він може видалити всі ваші файли, хочете ви того чи ні. Він може відредагувати / etc / passwd і взагалі може все. Як правило, пароль root знає тільки системний адміністратор. У повній згоді з О. він відповідає за все, що діється в системі, - якщо вже він все це в змозі змінити. Саме суперкористувачеві належить файл / etc / group. який визначає, в які ще групи. крім зазначених у / etc / passwd. входять користувачі системи.
Саме з нульовими ідентифікаторами користувача і групи запускається login. це дозволяє йому надалі "ставати будь-яким користувачем", змінюючи власні UID і GID. Багато інші системні дії теж вимагають прав root. але після здорового міркуванні можуть бути довірені звичайному (не супер) користувачеві. Наприклад, керувати чергою відсилаються електронних листів і передавати ці листи за призначенням може процес, який не має прав root. проте йому потрібен повний доступ до черги листів. З іншого боку, добре б, щоб ніякої справжній користувач системи - людина не могла навіть підглянути в цю чергу. Так виникають псевдопользователі - облікові записи. до яких не підходить ніякої пароль. Поле SHELL у псевдопользователя часто одно / sbin / nologin (програма видає This account is currently not available і негайно завершується), а поле HOME - / nonexistent (каталог, якого в системі немає). Зате система, запускаючи процес "від імені" такого псевдопользователя. буде впевнена, що нічого крамольного поза своєю компетенцією цей процес не зробить навіть в результаті помилки.
Користувач може сам поміняти собі пароль (а іноді SHELL і GECOS) за допомогою команди passwd. Це просте і досить буденне дію, з урахуванням усього сказаного вище, неможливо. Справді: процес, запущений користувачем, буде мати його UID, а файл passwd належить root. і тільки процесам з нульовим UID доступний для запису. Значить, необхідний механізм підміни ідентифікатора. дозволяє звичайним користувачам запускати процеси "від імені" інших, зокрема від імені root.
Для цього в файлової системі передбачено ще два атрибути - setuid і setgid. При запуску файлу, що має атрибут setuid. система створює процес, UID якого дорівнює UID цього файлу. а не UID процесу-батька. Така програма passwd. запустивши її, користувач отримує права root. але його дії обмежені можливостями цієї програми.
Як видно, ls відображає setuid як s на місці призначеного для користувача x-біта (x- біт нікуди не подівся, просто без нього setuid все одно не має сенсу). Подібним чином працює і setgid. наслідуючи GID процесу від виконуваного файлу. Підміна GID потрібна в тих випадках, коли необхідно і відкрити доступ до файлу, і зберегти реальний ідентифікатор користувача - наприклад, для запису рекордів в грі rogue. До речі, немає сенсу ставити setuid або setgid сценаріями. оскільки процес запуститься з файлу, що містить інтерпретатор. а файл зі сценарієм буде всього лише параметром командного рядка.
Навіть якщо passwd (або іншу утиліту, що займається аутентифікацією) не можна спровокувати нічого зробити понад встановленого, вона принаймні повинна прочитати файл з ключами від усіх паролів (shadow або master.passwd). Якщо якимось чином отримати доступ до пам'яті цього процесу, можна дістатися і до чужих ключів. Але ж насправді користувачеві, що змінює свій пароль. потрібна тільки рядок з власної обліковим записом. Щоб уникнути цієї - гіпотетичної - небезпеки, системи, в яких застосовується схема Trusted Computing Base (наприклад, ALT Linux), для кожного користувача тримають окремий файл / etc / tcb / имя_пользователя / shadow.
Варто відзначити, що сувора реалізація правил простої моделі безпеки (NoRU / NoWD - секретність або NoWU / NoRD - надійність) засобами UNIX неможлива. І справа навіть не в наявності довіреної суб'єкта - root. а в тому, що правила виду "No що-небудь Down" суперечать О. Згідно О і схемою доменної відповідальності. саме господар файлу визначає, чи відкривати до нього доступ. що рівносильно потоку WD.