Причины групп по умолчанию и пользователей в Linux

Взглянув на управление пользователями и группами по умолчанию на некоторых обычных дистрибутивах 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 требуется для установки привилегий на компакт-диске
  • Некоторые системы используют колесо для прав sudo; некоторые не
  • и т.п.

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


Однако, согласно базовой спецификации базового ядра Linux , только 3 пользователя, которые являются root, bin и daemon, абсолютно обязательны . Обоснованием других групп является:

Цель указания дополнительных пользователей и групп – уменьшить вероятность конфликтов имен между приложениями и дистрибутивами.

Поэтому кажется, что лучше держать эти группы на месте. Теоретически можно удалить их без поломки, хотя для некоторых «загадочные» вещи могут начать работать неправильно (например, некоторые страницы man не отображаются, если вы убиваете эту группу и т. Д.). Это не наносит вреда, чтобы оставить их там, и обычно предполагается, что все системы Linux будут иметь их.

Если мы все разделяем группу по умолчанию, как и в старые времена, нам нужно установить наш umask на 077, чтобы заблокировать группу. Если по умолчанию я, то я могу установить umask на 027, теперь, если я установил каталог файла в общую группу, эта группа может читать. Мне тоже не нужно возиться с режимами.

Это всего лишь один пример, но в целом это способ отключить группы до тех пор, пока они вам не понадобятся, что облегчит их включение и управление.

Вопрос 1: Рассуждение для одного и того же пользователя и группы

Привет, я ecyoung, и вы horgix. Мы работаем каждый день и заходим на тот же Linux-сервер, что и программисты. Однажды, недавно, наш системный администратор решил упростить создание и обслуживание пользователей, поэтому он отключил опцию USERGROUPS_ENAB и разместил всех существующих пользователей в новой группе users .


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


Если User / Group включен, если я создаю документ как ecyoung, тогда у меня есть права rwx. Поскольку в моей группе нет никого другого, когда они открывают мой документ, они видят пустую страницу с предупреждением. Это заставляет Сарбейнса-Оксли и Сод. Если я приглашу других пользователей, этим пользователям разрешен доступ к rw, и, делая это, я знаю, что то, что они видят, не вернется, чтобы укусить меня или их. Как говорили другие, если у себя дома такое разделение может быть для вас неважным. Если вы это определите, вы можете безопасно отключить этот параметр, и все пользователи будут добавлены в группу users с GID 100. См. Вопрос 2 ниже.

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


Вопрос 2: идентификаторы группы от 0 до 500

Идентификаторы группы и наоборот Идентификатор пользователя 0 – 500 зарезервированы для системных учетных записей и доступа к устройствам. Список стандартных системных групп приведен в списке стандартных учетных записей. Не удаляйте эти аккаунты вручную. Например, если вы хотите удалить ftp пользователя, удалите ftp-демона с вашей системой управления пакетами. Это также удалит системную учетную запись. Системные службы включают, но не ограничиваются:

  • Служба печати CUPS
  • Демо-сервер MySQL
  • Датчик FTP-сервера
  • Веб-сервер Apace
  • Разъем X Server для удаленных подключений
  • Демон Sound System ALSA
  • Служба DBUS

Есть и другие, поэтому, если другие читатели хотят добавить или удалить из списка услуг выше, сделайте это.

Группы пользователей могут иметь как «конфиденциальность в домашнем каталоге», так и «простое совместное использование в общих папках». Без групп пользователей вы можете использовать оба, но не оба. Подробности следуют:

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 ). Системы Plus использовались тесно связанной группой пользователей. Имело смысл иметь всех в группе users и делиться файлами по всей группе по групповым разрешениям. Никакой реальной заботы о безопасности, мало подозрительности дюжины или около того других пользователей. Все было локально, на одной машине. Нет сети для обмена информацией, например, через блог или так далее.

Сегодняшние системы Unix имеют сотни пользователей, требования к безопасности более жесткие, а пользователи (и процессы) могут принадлежать нескольким группам. Дайте каждому из (более невежественных) пользователей домашнюю группу и разрешите отклонение от него для совместного использования. Или используйте ACL.