Користувачі і групи в FreeBSD
Модель повноважень і користувачів, яка використовується в операційній системі FreeBSD і більшості систем сімейства UNIX досить проста і однорівнева. Не те, що Windows зі своїми вкладеними одна в іншу групами :-).
У FreeBSD існує тільки два типи користувачів: звичайні користувачі та привілейований користувач root. Ну і відповідно плоске простір груп.
На перший погляд може здатися, що ця схема менш практична, ніж схема Windows. Але все-таки у будь-який з схем є свої плюси і мінуси. Складна ієрархічна система груп, користувачів і повноважень Windows дозволяє більш гнучко налаштувати політику доступу, але також збільшує ймовірність того, що щось може піти не так. Та й велика ймовірність припуститися помилки, ступінь якої може варіюватися в широких межах. Гаразд б там, начальник не отримав доступ до своєї папці. А якщо все отримали доступ до закритих документів?
Кожен звичайний користувач системи FreeBSD наділений обмеженими повноваженнями і має закріплене за собою місце зберігання файлів (домашня директорія). Коли ми підключаємося до комп'ютера віддалено, то є там, як правило, рядовим користувачем. Ми відразу потрапляємо в свій домашній каталог, в якому можемо змінювати файли. І то тільки тому, що є їх власником.
Для того, щоб втілити себе суперкористувачем, використовуємо команду su. Буде потрібно ввести пароль суперкористувача, який є "ключем від всіх дверей" нашої системи. Після отримання доступу на рівні суперкористувача ми отримаємо такі можливості для створення або видалення файлів на комп'ютері, які не зможемо отримати ні на одній системі під керуванням Windows.
Важливо пам'ятати, що працюючи в системі під root потрібно дотримуватися підвищені заходи безпеки. Система не буде сумніватися в компетентності root-а, якщо він сказав - видалити важливі каталоги, значить так треба.
Для того, щоб виконати команду su, потрібно бути членом групи, званої "wheel". У цю групу входять ті користувачі, яким є повноважним ставати суперкористувачем.
"Хто всі ці люди?"
Є ще одна особливість. Поряд з реєструються користувачами (люди, які підключаються до системи), існують і автоматичні користувачі (bin, daemon, nobody, operator, www і інші). Ці облікові записи існують, щоб володіти деякими системними процесами. Важливо розуміти тут, що кожен процес, як і файл, повинен належати деякому користувачеві і всі процеси обмежені повноваженнями тих користувачів, яким вони належать.
Користувачі ніколи не звертаються до своїх файлів безпосередньо. Все, що робить користувач зі своїми файлами за допомогою команд - насправді виконує процес, від імені користувача. Процеси оперують файлами або іншими процесами. Процеси, що належать користувачеві ivan можуть працювати тільки з файлами і процесами, які належать користувачу ivan. У доступі може бути відмовлено, якщо один з цих процесів спробує змінити файл або процес користувача andrey.
Для чого ж потрібні псевдопользователі? Уявімо, що користувач ivan став раптом суперкористувачем. Всі процеси, що виконуються від імені ivan стануть мати абсолютну владу по відношенню до процесів іншого користувача. А що, якщо один з таких процесів читає особливий конфігураційний файл і змінює параметри системи? А що, якщо через якийсь помилки будь-хто може отримати доступ до конфігураційного файлу або іншим способом передати потенційно небезпечні параметри в програму, яка виконується з абсолютними правами? Система може бути знищена. Без питань і зайвих попереджень. Тому кожен сервіс має бути запущений від імені певного псевдопользователя і бути "замкненим" в просторі своїх "володінь", щоб ненароком не пошкодити решту системи.
Для чого потрібні групи?
Кожен користувач належить певній первинної групі, яка, як правило, має те ж ім'я, що і користувач. Фактично користувач є єдиним членом своєї первинної групи. Але ніщо не заважає нам створити групу, наприклад ftpusers і додати користувачів в неї. До речі, керувати приналежністю користувачів може тільки привілейований користувач root.
У загальному випадку групи потреби для того, щоб надати певним користувачам можливість спільної роботи з деякими файлами або процесами. Адже небажано, щоб різні люди використовували один обліковий запис, щоб отримати доступ до файлів, небажано, щоб один пароль був відомий комусь ще. І групи можуть надати різним користувачам рівні привілеї.