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

Значение по умолчанию для USERGROUPS_ENABin, по- /etc/login.defsвидимому, равно «yes», что отражается в «По умолчанию будет также создана группа для нового пользователя», которую можно найти в useraddman, поэтому каждый раз, когда создается новый пользователь, Группа создается с тем же именем и только в этом новом пользователе. Есть ли какая-либо польза от этого или это просто заполнитель?

Я чувствую, что мы теряем часть управления правами как пользователь / группа / другие , делая это. Было бы плохо иметь группу «пользователи» или «постоянные» или как вы хотите ее называть, это группа по умолчанию для каждого пользователя вместо того, чтобы иметь свою собственную?

Вторая часть моего вопроса, которая все еще основана на том, что я видел в Arch и Debian: по умолчанию создано много пользователей (FTP, HTTP и т. Д.). Есть ли в них смысл или они существуют только по историческим причинам?

Я думаю об их удалении, но не хочу ломать что-либо, что могло бы его использовать, но я никогда не видел, чтобы что-то делало, и понятия не имею, что может. То же самое касается групп по умолчанию (tty, mem и т. Д.), К которым я никогда не видел ни одного пользователя.

Группы пользователей

Я тоже не вижу много полезности в группах пользователей. Основной вариант использования - если пользователь хочет разрешить «друзьям» доступ к своим файлам, он может добавить пользователя-друга в свою группу. Немногие системы, с которыми я сталкивался, используют это таким образом.

Когда USERGROUPS_ENABв /etc/login.defsустановлен на «нет», useraddдобавляет все созданные пользователям группы , определенной в /etc/default/useraddв GROUPполе. В большинстве дистрибутивов это значение GID, 100которое обычно соответствует usersгруппе. Это позволяет вам иметь более общее управление пользователями. Затем, если вам нужно более точное управление, вы можете вручную добавить эти группы и добавить в них пользователей, что имеет смысл.

Созданные по умолчанию группы

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

• диск - это группа, которая владеет большинством дисковых устройств
• lp владеет параллельным портом (и иногда настраивается для прав администратора на чашках)
• uucp часто владеет последовательными портами (включая последовательные порты USB)
• CDROM требуется для монтирования прав на диске CD
• Некоторые системы используют колесо для прав sudo; некоторые не
• и т.п.

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

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

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

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

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

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

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

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

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

Вопрос 2: ID группы от 0 до 500

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

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

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

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

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

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

Unix - это многопользовательская система, будь то файловый сервер компании или ПК с 2 пользователями. «Конфиденциальность в вашем домашнем каталоге» может быть реализована несколькими способами:

Установите «umask 077», чтобы файлы создавались с rw для вас, а для других не было разрешений. Кроме того, 027 или 022, поэтому некоторые или все могут читать, но не записывать ваши файлы. Очевидным недостатком является невозможность совместной работы в общей папке, поскольку другие не могут работать с файлами, которые вы там создаете, из-за строгих разрешений. Вы можете изменить разрешения для таких файлов, но это «слишком много работы» и часто забывается.

Чтобы сотрудничать, вам нужно что-то вроде «umask 7», чтобы вы и группа-владелец могли читать и записывать созданные вами файлы. Это отлично подходит для общих папок и групп, состоящих из всех людей, которым нужен общий доступ. Но вы теряете конфиденциальность в вашей домашней папке!

Группа пользователей - это решение! Вы используете umask 7, поэтому все файлы, которые вы делаете, получают «rw для вас и rw для группы». Файлы в вашем домашнем каталоге создаются с вашей личной группой как «владеющая группа», поэтому никто другой не может получить доступ к этим файлам, несмотря на разрешение «group rw». Потому что никто, кроме вас, не входит в эту группу.

Вы все еще можете сотрудничать в общих папках. Файлы в общей папке получают «rw» для группы-владельца, и системный администратор устанавливает общую папку таким образом, чтобы общая группа (называемая соавторами) была владельцем группы для файлов в ней. Это делается путем создания этой группы соавторов, в которой участвуют все сотрудничающие пользователи. Затем администратор устанавливает принадлежность группы к общей папке «соавторам» и устанавливает разрешение SETGID для общей папки. При включенном SETGID все, что создано в общей папке, получит того же владельца группы, что и общая папка, то есть группа «соавторы». А с помощью umask 7 (или, альтернативно, 2) все участники этой группы будут иметь права на чтение и запись и смогут сотрудничать.

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

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