підсистема ідентифікації
Підсистемою облікових записів користується підсистема ідентифікації. яка в Linux має модульну структуру і називається PAM (Pluggable Authentication Modules, т. е. "Модулі ідентифікації"). Ідея PAM - в тому, щоб уніфікувати і, разом з тим, зробити більш гнучкими будь-які процедури ідентифікації в системі - починаючи від команди login і закінчуючи доступом до файлів по протоколу, скажімо, FTP. Для цього недостатньо просто написати "бібліотеку ідентифікації" і змусити всі програми її використовувати. Залежно від того, для чого проводиться ідентифікація. умови, при яких вона буде успішною, можуть бути більш або менш суворими, а якщо вона пройшла успішно, буває потрібно виконати дії, пов'язані ні з визначенням користувача, а з налаштуванням системи.
У більшості дистрибутивів PAM навчений схемою ".d", і налаштування кожної служби, яка використовує ідентифікацію. лежать в окремому файлі:
Приклад 12.8. Модулі ідентифікації (PAM)
У PAM визначено чотири випадки, що вимагають ідентифікації. auth - власне ідентифікація. визначення, чи той користувач, за кого він себе видає, account - визначення, чи все гаразд з обліковим записом користувача, password - зміна пароля в обліковий запис, і session - додаткові дії безпосередньо перед або безпосередньо після того, як користувач отримає доступ до затребуваної послузі. Ці значення приймає перше поле будь-якого файлу настройки з pam .d. а в третьому полі записується модуль. який перевіряє котрійсь із аспектів ідентифікації. Друге поле визначає, як успіх або неуспіх перевірки одного модуля впливає на загальний успіх або неуспіх ідентифікації даного типу (наприклад, required означає, що в разі неуспіху модуля перевірка пройдена не буде). Четверте і наступні поля відведені під параметри модуля:
Приклад 12.9. Налаштування PAM для login
Такі настройки login виявив Мефодій на своєму комп'ютері. У всіх чотирьох випадках використовується включається файл system-auth (до нього звертаються і інші служби), з деякими доповненнями. Так, під час ідентифікації pam_nologin.so додатково перевіряє, чи не заборонено чи користувачам реєструватися взагалі (як це буває за кілька хвилин до перезавантаження системи), а перед входом в систему і після виходу з неї pam_console.so виконує описану в лекції 6 "передачу прав на володіння пристроями "(і, відповідно, позбавлення користувача цих прав).
Каталог / etc / pam .d - чудовий приклад того, як профіль визначає поведінку системи. Зокрема, чотири перших рядки з system-auth показують, що в цьому дистрибутиві використовується не просто "тіньової" файл паролів, а схема TCB. описана в лекції 6. (Як уже відомо Мефодію, в цій схемі замість загального для всіх / etc / shadow задіяні файли виду / etc / tcb / входное_імя / shadow. причому права доступу до них влаштовані таким чином, щоб при виконанні команди passwd можна було обійтися без підміни призначеного для користувача ідентифікатора на суперпользовательскій).
Підсистема системних журналів
Всі події, про які повідомляється syslogd. підрозділяються горизонтально - за типом служби (facility), з якої ця подія відбулася, і вертикально - за ступенем його важливості (priority). Типів подій налічується близько двадцяти (серед них auth. Daemon. Kern. Mail і т. П. А також вісім різних неназваних, від local0 до local7). Ступенів важливості всього вісім, по зростанню: debug. info. notice. warning. err. crit. alert і emerg. Таким чином, кожна подія визначається парою значень, наприклад, mail.err означає для syslogd подія, пов'язана з поштою, притому важливості, неменшою err. З таких пар (з можливою заміною типу або важливості на "*", що означає "будь-які", або none, що означає "ніякі") складається конфігураційний файл /etc/syslog.conf:
Приклад 12.10. Налаштування системних журналів
У першому полі рядка вказуються профілі повідомлень, розділені символом ";", а в другому - сховище повідомлень (файл, термінал. Є способи віддавати їх на обробку програмі і пересилати по мережі). У прикладі в файл / var / log / messages потрапляють всі повідомлення важливості не меншою, ніж notice. за винятком повідомлень типу mail і authpriv. які потрапляють туди, тільки якщо мають важливість не нижче err. Повідомлення типу authpriv і auth будь важливості потрапляють в файл /var/log/security.log. а типу mail і важливості не нижче info - в файл / var / log / maillog. Повідомлення типу emerg (найвищої важливості) виводяться на всі термінали системи, і, нарешті, всі повідомлення виводяться на 12-ю віртуальну консоль.
У багатьох системах використовується грунтовно доопрацьований syslogd. дозволяє фільтрувати повідомлення не тільки по типу / важливості, а й, наприклад, по відправнику, задавати точні (а не «не менші") значення priority і т. п. однак такі доопрацювання потрібні для того, щоб або вести практично нефільтровану журнализацию (виходять системні журнали абсолютно нечитабельною обсягу), або відводити потік повідомлень певного служби в окремий журнал, знову-таки, не для читання, а для подальшої обробки.
Варто зауважити, що каталог /etc/syslog.d в нових версіях syslogd призначений для зберігання не профільних конфігураційних файлів в стилі ".d", а сокетов. з яких демон може отримувати повідомлення так само, як з мережі або в результаті системного виклику syslog ().