Переглянувши управління користувачами та групами за замовчуванням у деяких звичайних дистрибутивах Linux (відповідно ArchLinux та Debian), мені цікаво дві речі щодо цього та про наслідки зміни налаштувань та конфігурації за замовчуванням.

Значенням за замовчуванням для USERGROUPS_ENABв /etc/login.defsздається "так", що відображається "За замовчуванням для нового користувача також буде створена група", яку можна знайти в useraddлюдині, тому кожен раз, коли створюється новий користувач, група створена з тим самим іменем, і лише цей новий користувач в. Чи є користь від цього чи це просто заповнювач?

Я відчуваю, що таким чином ми втрачаємо частину управління правами як користувач / група / інші . Було б погано мати групу "користувачів" чи "постійних осіб", або як би ви цього не хотіли назвати, - це група за замовчуванням для кожного користувача, а не своя?

Друга частина мого запитання, яка все ще базується на тому, що я бачив в Arch та Debian: є багато користувачів, створених за замовчуванням (FTP, HTTP тощо). Чи є їм користь чи вони існують лише з історичних причин?

Я думаю про їх видалення, але не хочу зламати нічого, що могло б ним скористатися, але я ніколи не бачив нічого, щоб це зробити, і не маю уявлення, що міг би. Те саме стосується груп за замовчуванням (tty, mem тощо), до яких я ніколи не бачив, щоб жоден користувач належав.

Групи користувачів

Я також не бачу багато корисних у групах користувачів. Основний випадок використання - якщо користувач хотів дозволити "друзям" отримати доступ до своїх файлів, він може додати другого користувача до своєї групи. Кілька систем, з якими я стикався, насправді використовують це таким чином.

Коли USERGROUPS_ENABв /etc/login.defsустановлений на «ні», useraddдодає все створені користувачам групи , визначеної в /etc/default/useraddв GROUPполе. У більшості дистрибутивів це встановлено в GID, 100що зазвичай відповідає usersгрупі. Це дозволяє вам мати більш загальне управління користувачами. Потім, якщо вам потрібен тонший контроль, ви можете вручну додати ці групи та додати користувачів до них, що має сенс.

Створені за замовчуванням групи

Більшість з них виникли з історичних причин, але багато хто з них досі має дійсне використання:

• диск - це група, яка володіє більшості пристроїв дисковода
• lp володіє паралельним портом (а іноді налаштовується на права адміністратора на чашках)
• uucp часто володіє послідовними портами (включаючи послідовні порти USB)
• cdrom потрібен для монтажу привілеїв на компакт-диску
• Деякі системи використовують колесо для прав судо; деякі ні
• тощо.

Інші групи використовуються фоновими сценаріями. Наприклад, manгенерує тимчасові файли та такі під час його запуску; його процес використовує групу man для деяких із цих файлів і, як правило, очищає після себе.

Відповідно до стандартної базової специфікації Linux , лише 3 користувачі, котрі використовують root, bin та демон, є абсолютно обов'язковими . Обгрунтування позаду інших груп:

Метою визначення необов'язкових користувачів та груп є зменшення потенціалу конфліктів імен між додатками та дистрибутивами.

Так виглядає, як краще тримати ці групи на місці. Це theorically можна видалити їх без пошкодження, хоча для деяких, «таємничих» речі можуть почати працювати не права (наприклад, деякі сторінки людини не роблять , якщо ви вб'єте цю групу, і т.д.). Не залишає шкоди залишати їх там, і зазвичай вважається, що всі системи Linux будуть мати їх.

Питання 1: Обґрунтування того самого користувача та групи

Здрастуйте, я ecyoung, а ви хоргікс. Ми щодня ходимо на роботу і входимо в той самий Linux Server, що і програмісти. Одного разу, не так давно наш системний адміністратор вирішив полегшити створення та підтримку користувачів самим собою, тому він вимкнув цю USERGROUPS_ENABопцію та перемістив усіх існуючих користувачів у нову usersгрупу.

Це полегшило створення користувачів, але ви не потребуєте обслуговування, оскільки всі користувачі можуть отримати доступ до всіх інших файлів користувачів. У корпоративному середовищі це велике "ні, ні", через такі речі, як Сарбанес Окслі та " Сегрегація обов'язків" . Якщо я створюю файл A, груповий біт встановлюється в групу користувачів, а це означає, що всі користувачі можуть принаймні читати файл А. Якщо адміністратор sys лінивий, то в деяких випадках всі користувачі можуть RW-файл A. Це перемагає Сарбанаса Окслі і SoD, оскільки окремі відділи не повинні мати можливість читати набагато менше писати будь-які документи інших осіб.

Якщо користувач / група увімкнена, якщо я створюю документ як ecyoung, тоді лише у мене є права rwx на нього. Оскільки в моїй групі ніхто інший не знаходиться, коли вони відкривають мій документ, вони бачать порожню сторінку з попередженням. Це примушує Сарбанес-Окслі та СоД. Якщо я запрошую інших користувачів, цим користувачам дозволяється доступ rw, і тим самим я знаю, що те, що вони бачать, не повернеться, щоб кусати мене або їх. Як казали інші, якщо вдома, то ця розлука може бути неважливою для вас. Якщо ви визначите це, ви можете сміливо вимкнути цю опцію, і всі користувачі будуть додані до usersгрупи з GID 100. Див. Питання 2 нижче.

Гіпотетичний :
ви працюєте в ІТ, а Луїс працює в оплаті праці. Луї зберігає аркуш податку та нарахування заробітної плати у своєму домашньому довіднику, але ви обидва в групі користувачів, тому ви відкриваєте її домашній каталог, оскільки на ньому вказано + r для користувачів, і знаходите її електронну таблицю. Ви знаходите перелічену суму зарплати разом із Джо та Фредом. Ви думаєте, що Джо і Фред хотіли б, щоб ви знали їхню зарплату ??

Питання 2: Ідентифікатори групи від 0 до 500

Ідентифікатори групи та навпаки 0 - 500 ідентифікаторів користувача зарезервовані для системних облікових записів та доступу до пристроїв. Див. Таблицю попередньо налаштованих системних груп для переліку стандартних облікових записів. Будь ласка, не видаляйте ці акаунти вручну. Наприклад, якщо ви хочете видалити користувача ftp, видаліть демон ftp за допомогою системи управління пакетами. Це також видалить обліковий запис системи. Системні послуги включають, але не обмежуються ними:

• Поліграфічна служба CUPS
• Демон MySQL Server
• Демон сервера FTP
• Веб-сервер Apace
• Розетка сервера X для віддалених підключень
• Звукова система ALSA Daemon
• Служба DBUS

Є й інші, тож якщо інші читачі хочуть додати або видалити зі списку Сервісів вище, будь ласка, зробіть це.

Якщо всі ми поділяємо групу за замовчуванням, як колись, тоді нам потрібно встановити наш umask на 077, щоб заблокувати групу. Якщо я за замовчуванням - це я, то я можу встановити umask на 027, тепер, якщо я встановлю каталог файлів для спільної групи, ця група може читати. Мені також не доводиться возитися з режимами.

Це лише один приклад, але загалом це спосіб відключення груп, поки вони вам не потрібні, таким чином, щоб вони легше включали та керували.

Групи користувачів дозволяють вам мати "конфіденційність у вашому домашньому каталозі", а також "просту співпрацю в спільних папках". Без груп користувачів, ви можете мати і те, і інше. Деталі слідують:

Unix - це багатокористувацька система, будь то файловий сервер компанії або ПК з двома користувачами. "Конфіденційність у вашому домашньому каталозі" може бути реалізована декількома способами:

Встановіть "umask 077", щоб файли створювалися з rw для вас і не мали дозволів для інших. Крім того, 027 або 022, тому деякі або всі можуть читати, але не писати ваші файли. Очевидним недоліком є ​​те, що ви не можете співпрацювати у спільній папці, оскільки інші не можуть працювати над файлами, які ви створюєте там через суворі дозволи. Ви можете змінювати дозволи на такі файли, але це "занадто багато роботи" і часто забувається.

Для співпраці ви хочете щось на кшталт "umask 7", щоб і ви, і група, що володіє, могли читати та писати створені вами файли. Це чудово підходить для спільних папок і груп, що складаються з усіх людей, яким потрібен спільний доступ. Але ви втрачаєте конфіденційність у своїй домашній папці!

Група споживачів - це рішення! Ви використовуєте umask 7, тому всі створені вами файли отримують "rw для вас, а rw для групи". Файли у вашому домашньому каталозі створюються разом із вашою особистою групою як "група, що володіє", тому ніхто не може отримати доступ до цих файлів, незважаючи на дозвіл "group rw". Тому що ніхто, крім вас, не входить до цієї конкретної групи.

Ви все ще можете співпрацювати у спільних папках. Файли в загальній папці отримують "rw" для групи, що володіє, і sysadmin налаштовує спільну папку, щоб спільна група (звані колабораціоністами) була власником групи для файлів. Це робиться шляхом створення цієї групи співробітників, в якій усі співробітники користувачів. Потім адміністратор встановлює групове право власності на спільну папку на "колабораціоністів" і встановлює дозвіл SETGID на загальну папку. Якщо SETGID увімкнено, все, що створюється у спільній папці, отримає той самий власник групи, що й спільна папка, тобто група "колабораціоністів". І з umask 7 (або альтернативно 2), люди в цій групі всі матимуть доступ для читання + запису та зможуть співпрацювати.

Спочатку Unix-процеси могли одночасно належати одній групі (раніше була chgrp(1)команда, запитуючи пароль групи, що зберігається у полі пароля для пароля в /etc/groups). Плюс системи використовували тісно пов'язана група користувачів. Мало сенсу мати всіх у usersгрупі та ділитися всіма системами за груповими дозволами. Немає справжньої стисливості щодо безпеки, мало підозрілості з десяток користувачів колег. Все було місцевим, на одній машині. Немає мережі для обміну даними, наприклад, через блог чи так.

Сьогоднішні системи Unix мають сотні користувачів, вимоги безпеки є жорсткішими, і користувачі (і процеси) можуть належати до кількох груп. Надайте кожному з (більш незрозумілих) користувачів домашню групу та дозвольте відмовитися від неї для обміну. Або використовувати ACL.