Gid что это linux
Пользователи в Linux
Учётные записи
Linux — система многопользовательская, а потому пользователь — ключевое понятие для организации всей системы доступа в Linux. Когда пользователь регистрируется в системе (проходит процедуру авторизации, например, вводя системное имя и пароль), он идентифицируется с учётной записью, в которой система хранит информацию о каждом пользователе: его системное имя и некоторые другие сведения, необходимые для работы с ним. Именно с учётными записями, а не с самими пользователями, и работает система. Ниже приведён список этих сведений.
Системное имя (user name)
Идентификатор пользователя (UID)
Идентификатор группы (GID)
Полное имя (full name)
Помимо системного имени в учётной записи содержится и полное имя (имя и фамилия) использующего данную учётную запись человека. Конечно, пользователь может указать что угодно в качестве своего имени и фамилии. Полное имя необходимо не столько системе, сколько людям — чтобы иметь возможность определить, кому принадлежит учётная запись.
Домашний каталог (home directory)
Файлы всех пользователей в Linux хранятся раздельно, у каждого пользователя есть собственный домашний каталог, в котором он может хранить свои данные. Доступ других пользователей к домашнему каталогу пользователя может быть ограничен. Информация о домашнем каталоге обязательно должна присутствовать в учётной записи, потому что именно с него начинает работу пользователь, зарегистрировавшийся в системе.
Начальная оболочка (login shell)
Важнейший способ взаимодействовать с системой Linux — командная строка, которая позволяет пользователю вести «диалог» с системой: передавать ей команды и получать её ответы. Для этой цели служит специальная программа — командная оболочка (или интерпретатор командной строки), по-английски — shell. Начальная оболочка (login shell) запускается при входе пользователя в систему в текстовом режиме (например, на виртуальной консоли). Поскольку в Linux доступно несколько разных командных оболочек, в учётной записи указано, какую из командных оболочек нужно запустить для данного пользователя. Если специально не указывать начальную оболочку при создании учётной записи, она будет назначена по умолчанию, вероятнее всего это будет bash.
Управление пользователями
Создание пользователей
Все эти действия могут быть выполнены и вручную, однако это довольно неудобно и можно что-нибудь забыть. Для упрощения процесса используется утилита useradd (она же по традиции называется adduser ), для выполнения которой, естественно, потребуются полномочия администратора. В простейшем случае достаточно будет двух шагов:
1Это может оказаться важным, например, в такой ситуации: учётную запись пользователя с именем test удалили из системы, а потом добавили снова. Однако с точки зрения системы это уже другой пользователь, потому что у него другой UID.
2Обычно Linux выдаёт нормальным пользователям UID, начиная с “ 500 ” или “ 1000 ”.
3Как правило, численное значение GID в этом случае совпадает со значением UID.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
У каждого файла обязательно есть владелец и группа, которой он принадлежит. На этой схеме строится классическая система прав в Linux и UNIX: владелец, группа и остальные. Более подробно о ней вы можете прочитать в предыдущих частях нашего цикла:
Таким образом пользователи и группы определяют доступ не только к файлам в привычном нам понимании, но и ко всему спектру объектов операционной системы: процессам, устройствам, сокетам. Просто запомните, что все есть файл, а каждый файл имеет владельца и группу.
Давайте рассмотрим его структуру подробнее. Каждая строка соответствует одному пользователю и имеет следующий формат:
С именем пользователя все понятно, а вот второй параметр может вызвать некоторое недоумение. Когда-то давно пароли хранились в открытом виде, о чем намекает само название файла, но затем от этой практики отказались и современные системы не хранят пароли в каком-либо виде вообще, хранится только сформированный по специальному алгоритму хеш, такие пароли в Linux называются затененными ( shadow). Для такого пароля во втором поле всегда ставится символ x.
Этим часто пользуются злоумышленники, один из типовых сценариев проникновения предусматривает создание пользователя с неприметным именем, но идентификаторами root, что позволяет действовать в системе от имени суперпользователя не привлекая ненужного внимания.
В реальных сценариях данную возможность использовать не следует, так как наличие таких пользователей может вызвать конфликты в системе. Например, Gnome 3 в Debian 10 просто отказался загружаться после того, как мы создали такого пользователя.
В поле комментарий можно написать все что угодно, определенного формата в современных системах нет, но исторически данное поле называется GECOS и подразумевает перечисление через запятую следующих опций:
Следующие два поля указывают на домашнюю директорию пользователя и его командную оболочку. Разным пользователям можно назначить разные командные оболочки, скажем, ваш коллега предпочитает zsh, то вы можете без проблем назначить ему любимую оболочку.
Рассмотрение командных оболочек Linux выходит за рамки данной статьи, поэтому мы оставим эту тему, но расскажем о двух специализированных «оболочках», которые указывают, когда пользователю запрещен интерактивный вход в систему. Это обычно применяется для служб и пользователей от имени которых исполняются некоторые скрипты. Даже если такая учетная запись будет скомпрометирована войти в консоль с ней не удастся.
Обычно для этой цели используется:
В современных системах директория /sbin является символической ссылкой на /usr/sbin. Реже используется «оболочка»:
Разница между ними заключается в том, что /bin/false просто запрещает вход в систему, а /sbin/nologin выдает сообщение:
Предупреждение! Данная команда уничтожает корневую файловую систему, что приводит к ее полной неработоспособности и потере всех данных. Приведена сугубо в качестве примера.
Современные дистрибутивы по умолчанию блокируют выполнение явно деструктивных команд, но не запрещают их, все это выглядит как предупреждение: «так делать опасно, но если ты настаиваешь. «
С учетом вышесказанного есть ряд сложившихся правил работы с этим пользователем. Во-первых, не следует выполнять из-под учетной записи суперпользователя повседневную работу. Для разовых действий используйте sudo, для административных работ допустимо временно повышать привилегии с последующим обязательным выходом. Во-вторых, доступ к данной учетной записи должен быть тщательно ограничен, потому как утеря контроля над root равносильно полной потере контроля над системой.
Существует соглашение, что этот диапазон идентификаторов используется только системными службами и в нем не должно быть обычных пользователей. Однако никто не мешает назначить службе UID выше 1000, а пользователю менее 999, но никаких последствий это иметь не будет и никак не скажется на привилегиях. Это разделение чисто условное и предназначено для повышения удобства администрирования. Встретив в незнакомой системе пользователя с UID до 999, вы будете с большой долей вероятности предполагать, что это служба.
Но это тоже условность, скажем в отсутствии установленного веб-сервера мы можем назначить «зарезервированный» UID другому пользователю без каких-либо последствий, веб-сервер при установке возьмет ближайший свободный UID, но такие действия безусловно являются дурным тоном.
Многое стороннее ПО, например, сервер 1С и сборки PostgresPro занимают ближайшие свободные идентификаторы с верхнего конца диапазона: 999, 998 и т.д.
Из всего изложенного выше вы должны понимать, что система определяет пользователей по идентификаторам, а не по именам, а присвоение идентификаторов регулируется определенными правилами, но никакие из них, кроме двух специальных (0 для root и 65534 для nobody), не дают каких-либо дополнительных прав или привилегий.
Для более гибкого управления пользователями предназначены группы, они позволяют объединять пользователей по любому произвольному принципу и назначать им дополнительные права. Если мы хотим разрешить пользователю повышение прав, то мы включаем его в группу sudo, при этом мы всегда можем легко узнать, кто именно обладает такой возможностью, достаточно посмотреть участников группы.
Посмотреть список групп можно в файле /etc/group
Он имеет следующий формат:
После того как мы добавим пользователей в группу они будут перечислены в последнем поле через запятую.
Давайте внимательно посмотрим на скриншот и проанализируем членство созданного при установке пользователя andrey в дополнительных группах. Практически все они связанны с доступом к оборудованию или дают возможность использовать некоторые системные механизмы, скажем группа plugdev предоставляет возможность монтировать съемные устройства.
В современных системах, при работе в графических средах доступ к оборудованию часто предоставляется механизмами рабочей среды, которые не используют разделение прав на основе членства пользователя в соответствующих группах. Поэтому, если вы используете стандартные механизмы дистрибутива, то для полноценного использования оборудования вам нет необходимости включать пользователя в дополнительные группы. Однако это может потребоваться при работе в консоли или при использовании нестандартных или специализированных устройств в графической среде.
Синтаксис этого файла предусматривает девять полей, содержащих следующую информацию:
Наибольший интерес представляет второе поле, содержащее хеш пароля, оно имеет структуру:
В современных системах используется наиболее стойкий хеш SHA-512.
Соль позволяет исключить атаки при помощи заранее вычисленных значений и при ее случайном значении позволяет скрыть наличие у пользователей одинаковых паролей. На скриншоте выше пользователям ivan и maria были установлены одинаковые пароли, но за счет различной соли они имеют различный хеш.
Для групп используется аналогичный по назначению файл /etc/gshadow
Его структура более проста, а поля имеют следующее назначение:
Поле пароля также может содержать спецсимволы и также как для пользователей символ * используется преимущественно для системных групп, а ! для групп пользователей. По умолчанию пароли групп отсутствуют и вход в них заблокирован, т.е. никто, кроме членов группы, не может войти в группу, а членам пароль не нужен.
Так как данные о пользователях являются критичными для системы, то указанные выше файлы крайне не рекомендуется изменять вручную, а для управления пользователями и группами следует использовать специальные утилиты, о которых мы поговорим в следующей части. При любом изменении информации в них штатными инструментами система создает резервную копию предыдущей версии файла с добавлением в конце имени символа
Поэтому даже если что-то пойдет не так, всегда есть возможность (при условии физического доступа к системе) восстановить состояние этих файлов на момент перед внесением изменений в конфигурацию. В качестве примера приведем следующую ситуацию: вы случайно удалили единственного пользователя с административными правами из группы sudo, root при этом заблокирован, после завершения сеанса в системе не останется ни одного привилегированного пользователя.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Все, что вам нужно знать о UID в Linux
Главное меню » Операционная система Linux » Все, что вам нужно знать о UID в Linux
Что такое UID в Linux?
UID обозначает идентификатор пользователя. UID – это номер, назначенный каждому пользователю Linux. Это представление пользователя в ядре Linux.
UID используется для идентификации пользователя в системе и для определения того, к каким системным ресурсам пользователь может получить доступ. Вот почему идентификатор пользователя должен быть уникальным.
Вы можете найти UID в файле /etc/passwd. Это тот же файл, который можно использовать для составления списка всех пользователей в системе Linux.
Используйте команду Linux для просмотра текстового файла, и вы увидите различную информацию о пользователях, присутствующих в вашей системе.
Третье поле здесь представляет идентификатор пользователя или UID.
Обратите внимание, что в большинстве дистрибутивов Linux UID 1-500 обычно зарезервирован для системных пользователей. В Ubuntu и Fedora UID для новых пользователей начинаются с 1000.
Например, если вы используете команду useradd или adduser для создания нового пользователя, он получит следующий доступный номер после 1000 в качестве своего UID.
Как найти UID пользователя в Linux?
Вы всегда можете положиться на файл /etc/passwd, чтобы получить UID пользователя. Это не единственный способ получить информацию UID в Linux.
Команда id в Linux отобразит UID, GID и группы, к которым принадлежит ваш текущий пользователь:
Вы также можете указать имена пользователей с помощью команды id, чтобы получить UID любого пользователя Linux:
Как изменить UID пользователя в Linux?
Предположим, у вас было несколько пользователей в вашей системе Linux. Вы должны были удалить пользователя, потому что он/она покинул организацию. Теперь вы хотите, чтобы его UID был занят другим пользователем, уже находящимся в системе.
Вы можете изменить UID, изменив пользователя с помощью команды usermod следующим образом:
Вы должны иметь привилегию суперпользователя для выполнения вышеуказанной команды.
Вы помните концепцию прав доступа и владения файлами в Linux? Право собственности на файл определяется UID пользователя-владельца.
Когда вы обновляете UID пользователя, что происходит с файлами, принадлежащими этому пользователю? В то время как все файлы в домашнем каталоге user_2 изменят свой связанный UID, вам придется вручную обновить связанный UID других файлов вне домашний каталог.
Что вы можете сделать, это вручную обновить владельца файлов, связанных со старым UID пользователя_2.
Вот и все. Мы надеемся, что теперь у вас есть лучшее представление об UID в Linux. Не стесняйтесь задавать свои вопросы, если таковые имеются.
Как профессиональный пользователь Linux, если вы думаете, что мы пропустили какое-то важное понятие об UID, пожалуйста, дайте мне знать в разделе комментариев.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Изменение UID&GID пользователя и его файлов
Встала тут передо мной задача изменить UID и GID пользователя и правильно изменить владельца всех файлов.
Дело в том, что я работаю за двумя компьютерами попеременно, и файлы mysql лежат у меня на флешке. Получилось так, что id пользователя mysql на обоих компах отличается и мускл не может получить доступ к своим файлам. Присваивать права 0666 скучно, и по этому поводу я решил научиться грамотно изменять uid пользователя 🙂
Изменение идентификатора пользователя и группы
Поиск осиротевших файлов
Однако такой способ не принесёт желаемого результата: некоторые файлы, владельцем которых был ‘mysql:root’ станут принадлежать ‘mysql:mysql’. А мы ведь договорились сделать всё предельно правильно 🙂 Следовательно, поиск по user и по group надо вести отдельно.
Можно выполнить подряд две команды find:
и это уже будет намного ближе к истине, но тогда find ‘у придётся дважды шуршать по всему жёсткому диску.
После недолгого поиска все файлы будут найдены.
Также в исключения можно внести путь к диску с бекапом (он ведь у вас есть, верно? ;), подмонтированные сетевые шары и прочее.
Финиш
Проверка
Если всё было сделано правильно (и в системе не водилось осиротевших файлов) — команда не должна ничего вывести.
Полный код скрипта
Надеюсь, статья окажется полезной. Рекомендую ближе ознакомиться с синтаксисом этой команды: она ведь намного мощнее чем вы думаете 🙂
Напоследок приведу полный код скрипта для смены UID&GID пользователя и его файлов:
Права доступа
Работая с Linux, Мефодий заметил, что некоторые файлы и каталоги недоступны ему ни на чтение, ни на запись, ни на использование. Зачем такие нужны? Оказывается, другие пользователи могут обращаться к этим файлам, а у Мефодия просто не хватает прав.
Идентификатор пользователя
Говоря о правах доступа пользователя к файлам, стоит заметить, что в действительности манипулирует файлами не сам пользователь, а запущенный им процесс (например, утилита rm или cat ). Поскольку и файл, и процесс создаются и управляются системой, ей нетрудно организовать какую угодно политику доступа одних к другим, основываясь на любых свойствах процессов как субъектов и файлов как объектов системы.
В Linux, однако, используются не какие угодно свойства, а результат идентификации пользователя — его UID. Каждый процесс системы обязательно принадлежит какому-нибудь пользователю, и идентификатор пользователя (UID) — обязательное свойство любого процесса Linux. Когда программа login запускает стартовый командный интерпретатор, она приписывает ему UID, полученный в результате диалога. Обычный запуск программы ( exec() ) или порождение нового процесса ( fork() ) не изменяют UID процесса, поэтому все процессы, запущенные пользователем во время терминальной сессии, будут иметь его идентификатор.
Поскольку UID однозначно определяется входным именем, оно нередко используется вместо идентификатора — для наглядности. Например, вместо выражения «идентификатор пользователя, соответствующий входному имени methody », говорят «UID methody » (в примере ниже этот идентификатор равен 503 ).
[methody@localhost methody]$ id
uid=503(methody) gid=503(methody) группы=503(methody)
[methody@localhost methody]$ id shogun
uid=400(shogun) gid=400(shogun) группы=400(shogun),4(adm),10(wheel),19(proc)
Пример 1. Как узнать идентификаторы пользователя и членство в группах
Идентификатор группы
Здесь есть тонкость. В файле group указываются не идентификаторы, а входные имена пользователей. Формально говоря, можно создать двух пользователей с одинаковым UID, но разными GID и списками групп. Обычно так не делают: надобности — почти никакой, а неразберихи возникнет много.
Часто процедуру создания пользователя проектируют так, что имя группы по умолчанию совпадает с входным именем пользователя, а GID пользователя — с его UID. Однако это совсем не обязательно: не всегда нужно заводить для пользователя отдельную группу, а если заводить, то не всегда удаётся сделать так,чтобы желаемый идентификатор группы совпадал с желаемым идентификатором пользователя.
Ярлыки объектов файловой системы
При создании объектов файловой системы — файлов, каталогов и т. п. — каждому в обязательном порядке приписывается ярлык. Ярлык включает в себя UID — идентификатор пользователя-хозяина файла, GID — идентификатор группы, которой принадлежит файл, тип объекта и набор т. н. атрибутов, а также некоторую дополнительную информацию. Атрибуты определяют, кто и что с файлом имеет право делать, и описаны ниже.
Пример от рута есть смысл приводить только в том случае, если пример на что-то совершенно универсальное, что обязательно будет устроено точно так же в любом Линуксе. Иначе есть опасность, что пользователь начнёт мудрить — и что он там намудрит. В Linux определено несколько системных групп, задача которых — обеспечивать доступ членов этих групп к разнообразным ресурсам системы. Часто такие группы носят говорящие названия: « disk », « audio », « cdwriter » и т. п. Тогда обычным пользователям доступ к некоторому файлу, каталогу или файлу-дырке Linux закрыт, но открыт членам группы, которой этот объект принадлежит.
Например, в Linux почти всегда используется виртуальная файловая система /proc — каталог, в котором в виде подкаталогов и файлов представлена информация из таблицы процессов. Имя подкаталога /proc совпадает с PID соответствующего процесса, а содержимое этого подкаталога отражает свойства процесса. Хозяином такого подкаталога будет хозяин процесса (с правами на чтение и использование), поэтому любой пользователь сможет посмотреть информацию о своих процессах. Именно каталогом /proc пользуется утилита ps :
» означает домашний каталог. Этим сокращением удобно пользоваться, если текущий каталог — не домашний, а оттуда (или туда) нужно скопировать файл. Получается команда наподобие « cp
Более точно — обо всех процессах, имеющих право выводить на какой-нибудь терминал, а значит, запущенными из терминального сеанса.
Разделяемые каталоги
Проанализировав систему прав доступа к каталогам в Linux, Мефодий пришёл к выводу, что в ней имеется существенный недочёт. Тот, кто имеет право изменять каталог, может удалить любой файл оттуда, даже такой, к которому совершенно не имеет доступа. Формально всё правильно: удаление файла из каталога — всего лишь изменение содержимого каталога. Если у файла было больше одного имени (существовало несколько жёстких ссылок на этот файл), никакого удаления данных не произойдёт, а если ссылка была последней — файл в самом деле удалится. Вот это-то, по мнению Мефодия, и плохо.
Чтобы доказать новичку, что право на удаление любых файлов полезно, кто-то создал прямо в домашнем каталоге Мефодия файл, совершенно ему недоступный, да к тому же с подозрительным именем, содержащим пробел:
Убедившись, что любой доступ в каталог /tmp открыт всем, Мефодий захотел удалить оттуда все файлы. Затея гораздо более хулиганская, чем заведение файла: а вдруг они кому-нибудь нужны? Удивительно, но удалить удалось только файл, принадлежащий самому Мефодию.
При установке атрибута « t » доступ на использование для посторонних (« t » в строчке атрибутов стоит на месте последнего « x ») не отменяется. Просто они так редко используются друг без друга, что ls выводит их в одном и том же месте. Если кому-нибудь придёт в голову организовать разделяемый каталог без доступа посторонним на использование, ls выведет на месте девятого атрибута не « t », а « T ».
Суперпользователь
Мефодий изрядно возмутился, узнав, что кто-то может проделывать над ним всякие штуки, которые сам Мефодий ни над кем проделывать не может. Обоснованное подозрение пало на Гуревича, единственного администратора этой системы, обладающего правами суперпользователя.
суперпользователь Единственный пользователь в Linux, на которого не распространяются ограничения прав доступа. Имеет нулевой идентификатор пользователя.
Среди учётных записей Linux всегда есть запись по имени root («корень»), соответствующая нулевому идентификатору, поэтому вместо «суперпользователь» часто говорят «root».
Вместо полного имени такому пользователю часто пишут «root of all evil».
Подмена идентификатора
В Linux этот механизм называется подменой идентификатора и устроен очень просто. Процесс может сменить свой UID, если запустит вместо себя при помощи exec() другую программу из файла, имеющего специальный атрибут SetUID.
Строго говоря, при этом меняется не собственно идентификатор пользователя, а т. н. исполнительный идентификатор пользователя, EUID; это нужно для того, чтобы знать, кто на самом деле запустил программу.
В этом случае UID процесса становится равным UID файла, из которого программа была запущена.
Вполне очевидно, что подмена идентификатора распространяется на программы, но не работает для сценариев. В самом деле, при исполнении сценария процесс запускается не из него, а из программы-интерпретатора. Файл со сценарием передаётся всего лишь как параметр командной строки, и подавляющее большинство интерпретаторов просто не обращают внимания на атрибуты этого файла. Интерпретатор наследует UID у родительского процесса, так что если он и обнаружит SetUID у сценария, поделать он всё равно ничего не сможет.