uid gid что это

Пользователи в 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.

Источник

[Пост] Управление доступом в Linux

Jan 10, 2018 • zinvapel

Основные правила управления доступом

Объекты (например, файлы и процессы) имеют владельцев. Владельцы обладают обширным (но необязательно неограниченным) контролем над своими объектами.

Основное

Под каждого пользователя, создается свой каталог, пользователю назначается командная оболочка (командный интерпретатор, используемый в операционных системах семейства UNIX). Например: /bin/bash, /bin/zsh, /bin/sh и другие.

Каждому пользователю назначается идентификационный номер (User ID). Сокращенно номер обозначается как UID, является уникальным идентификатором пользователя. Операционная система отслеживает пользователя именно по UID, а не по их имени.

Также, каждому пользователю назначается пароль для входа в систему.

Каждый пользователь принадлежит минимум к одной или нескольким группам.

Помимо пользователей, существуют группы. Так же как и пользователь, группа обладает правам доступа к тем или иным каталогам, файлам, периферии. Для каждого файла определён не только пользователь, но и группа. Группы группируют пользователей для предоставления одинаковых полномочий на какие-либо действия.

Каждой группе назначается идентификационный номер (group ID). Сокращённо GID, является уникальный идентификатором группы. Принадлежность пользователя к группе устанавливается администратором.

Управление пользователями

Просмотр

Каждый аккаунт занимает одну строку, в формате account:password:UID:GID:GECOS:directory:shell

Получение информации о пользователях

Добавление пользователя

Добавление пользователя осуществляется при помощи команды useradd.

sudo useradd vasyapupkin

Изменение пользователя

Изменение параметров пользователя происходит с помощью утилиты usermod. Пример использования:

Изменить пароль пользователю можно при помощи утилиты passwd.

sudo passwd vasyapupkin

Утилита passwd может использоваться и обычным пользователем для смены пароля.

Основные ключи passwd:

Установка пустого пароля пользователя

Супер пользователь с помощью утилит командной строки passwd и usermod или путем редактирования файла /etc/shadow может удалить пароль пользователь, дав возможность входить в систему без указания пароля.

После этого имеет смысл принудить пользователя установить себе новый пароль при следующем входе в систему.

Удаление пользователя

Для того, чтобы удалить пользователя воспользуйтесь утилитой userdel.

sudo userdel vasyapupkin

Управление группами

Создание группы

Программа groupadd создаёт новую группу согласно указанным значениям командной строки и системным значениям по умолчанию.

sudo groupadd testgroup

Изменение группы

Сменить название группы, ее GID или пароль можно при помощи groupmod.

Удаление группы

Утилита groupdel не имеет никаких дополнительных параметров.

sudo groupdel testgroup

Управление пользователями группы

Для управления пользователями группы используется утилита gpasswd. Чтобы занести пользователя в группу:

Вывод пользователя из группы:

Файлы конфигурации

/etc/passwd

В файле /etc/passwd, который упоминался ранее, хранится вся информация о пользователях кроме пароля. Одна строка из этого файла соответствует описанию одного пользователя. Примерное содержание строки таково:

Строка состоит из нескольких полей, каждое из которых отделено от другого двоеточием. Значение каждого поля:

Второе и последнее поля необязательные и могут не иметь значения.

/etc/group

В /etc/group, как очевидно из названия хранится информация о группах. Она записана в аналогичном /etc/passwd виде:

Строка состоит из нескольких полей, каждое из которых отделено от другого двоеточием. Значение каждого поля:

В этом файле второе и четвертое поля могут быть пустыми.

/etc/shadow

Файл /etc/shadow хранит в себе пароли, по этому права, установленные на этот файл, не дают считать его простому пользователю. Пример одной из записей из этого файла:

Sudo и su

Программа su служит для выполнения от имени указанного пользователя (по умолчанию — root) указанной команды/программы (по умолчанию — той программы, что определена в качестве оболочки (shell) для указанного пользователя) и запрашивает она пароль указанного пользователя.

О программе sudo можно сказать почти то же самое, за двумя исключениями:

Управление доступом

Собственно inode является, как идентификатором файла/каталога, так и сущностью, которая содержит в себе информацию о файле/каталоге. Например такую, как: принадлежность к владельцу/группе, тип файла и права доступа к файлу.

Для каждого объекта файловой системы в модели полномочий Linux есть три типа полномочий:

В полномочия записи входят также возможности удаления и изменения объекта. Право выполнения можно установить для любого файла. Потенциально, любой файл в системе можно запустить на выполнение, как программу в Windows. В Linux является ли файл исполняемым или нет, определяется не по его расширению, а по правам доступа. Кроме того, эти полномочия указываются отдельно для владельца файла, членов группы файла и для всех остальных.

Кроме указанного представления полномочий доступа (символьного), существует так же и числовое представление. Для общего понимания, приведу таблицу соответствия числового (двоичного и десятичного) значения прав доступа и буквенного:

Управление правами доступа

Управление правами доступа происходит с помощью команды chmod, управление владельцем файла происходит с помощью команды chown. Синтаксис команд следующий:

Использование команды chown выглядит следующим образом: chown user:group file (-R рекурсивно)

Права доступа к символьным ссылкам

Если посмотреть на права символьных ссылок, то они всегда выглядят так: rwxrwxrwx. Дело в том, что права на символьную ссылку не имеют особого значения. При использования ссылки драйвер файловой системы пересчитывает реальный путь к файлу и применяет права доступа, определенные для реального пути уже без учета символьной ссылки.

Специальные атрибуты

Хотелось бы так же провести аналогию с ОС Windows. В указанной операционной системе права регулируются на основе списков ACL. В Linux тоже такое возможно, это реализуется с помощью пакета acl, но данный вопрос в текущей теме я рассматривать не буду. Еще одно важное замечание! В Windows можно определить права доступа на каталог, и они автоматически распространяются на все файлы и поддиректории (если вы явно не указали иного). В Linux права доступа сохраняются в inode файла, и поскольку inode у каждого файла свой собственный, права доступа у каждого файла свои. Так же, права доступа пользователя и группы не суммируются, как в Windows. Если программа выполняется с правами пользователя и группы, которым принадлежит файл — работают только права хозяина файла.

Исполняемый файл с установленным атрибутом suid является “потенциально опасным”. Без установленного атрибута, файл не позволит обычному пользователю сделать то, что выходит за пределы прав пользователя (пример, программа passwd позволяет пользователю изменить только собственный пароль). Но, даже незначительная ошибка в такой программе может привести к тому, что злоумышленник сможет заставить её выполнить ещё какие-нибудь действия, не предусмотренные автором программы. Стоит очень осторожно относиться к данным атрибутам! Как найти в системе файлы с атрибутом SIUD и др.

При создании новой директории в директории с уже установленным SGID-битом, у созданной директории SGID-бит устанавливается автоматически!

Обозначение атрибутов Sticky, SUID, SGID

Права доступа по-умолчанию для вновь создаваемых объектов файловой системе.

В Linux, при создании какого-либо файла или каталога предоставляемые права определяются по определенному алгоритму (формуле). Не вдаваясь в подробности и для большего понимания сути скажу, что есть исходные права доступа:

Узнать текущий umask можно, введя команду umask без параметров. Пример:

Источник

Пользователь в Docker

Андрей Копылов, наш технический директор, любит, активно использует и пропагандирует Docker. В новой статье он рассказывает, как создать пользователей в Docker. Правильная работа с ними, почему пользователей нельзя оставлять с root правами и, как решить задачу несовпадения идентификаторов в Dockerfile.

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

Всегда есть баги, которые позволят зловреду выбраться из контейнера и попасть на хостовый компьютер. Предполагая худшее, мы должны обеспечить запуск процессов внутри контейнера от пользователя, который не имеет никаких прав на хостовой машине.

Создание пользователя

Создание пользователя в контейнере не отличается от его создания в линуксовых дистрибутивах. Однако для разных базовых образов команды могут различаться.

Для дистрибутивов основанных на debian в Dockerfile необходимо добавить:

Запуск процессов от пользователя

Для запуска всех последующих процессов от пользователя с UID 2000 выполните:

Для запуска всех последующих процессов от пользователя node выполните:

Монтирование томов

При монтировании томов внутрь контейнера обеспечьте пользователю возможность читать и (или) писать файлы. Для этого UID (GID) пользователя в контейнере и пользователя за пределами контейнера, у которого есть соответствующие права на доступ к файлу, должны соответствовать. При этом имена пользователей значения не имеют.

Часто на линуксовом компьютере у пользователя UID и GID равны 1000. Эти идентификаторы присваиваются первому пользователю компьютера.

Узнать свои идентификаторы просто:

Вы получите исчерпывающую информацию о своем пользователе.
Замените 2000 из примеров на свой идентификатор и все будет в порядке.

Присвоение пользователю UID и GID

Если пользователь создан ранее, но необходимо изменить идентификаторы, то можно сделать это так:

Если вы используете базовый образ alpine, то нужно установить пакет shadow:

Передача идентификатора пользователя внутрь контейнера при построении образа

Если ваш идентификатор и идентификаторы всех людей, которые работают над проектом, совпадают, то достаточно указать этот идентификатор в Dockerfile. Однако часто идентификаторы пользователей не совпадают.

Как осуществить желаемое не сразу понятно. Для меня это было самым сложным в процессе освоения docker. Многие пользователи docker не задумываются о том, что есть разные этапы жизни образа. Сначала образ собирается для этого используют Dockerfile. При запуске контейнера из образа Dockerfile уже не используется.

Создание пользователей должно происходить при построении образа. Это же касается и определения пользователя, из-под которого запускаются процессы. Значит, что мы каким-то образом должны передать внутрь контейнера UID (GID).

Для использования внешних переменных в Dockerfile служат директивы ENV и ARG. Подробное сравнение директив тут.

Передать аргументы через docker-compose можно так:

Источник

Изменение UID&GID пользователя и его файлов

Встала тут передо мной задача изменить UID и GID пользователя и правильно изменить владельца всех файлов.
Дело в том, что я работаю за двумя компьютерами попеременно, и файлы mysql лежат у меня на флешке. Получилось так, что id пользователя mysql на обоих компах отличается и мускл не может получить доступ к своим файлам. Присваивать права 0666 скучно, и по этому поводу я решил научиться грамотно изменять uid пользователя 🙂

Изменение идентификатора пользователя и группы

Поиск осиротевших файлов

Однако такой способ не принесёт желаемого результата: некоторые файлы, владельцем которых был ‘mysql:root’ станут принадлежать ‘mysql:mysql’. А мы ведь договорились сделать всё предельно правильно 🙂 Следовательно, поиск по user и по group надо вести отдельно.

Можно выполнить подряд две команды find:

и это уже будет намного ближе к истине, но тогда find ‘у придётся дважды шуршать по всему жёсткому диску.

После недолгого поиска все файлы будут найдены.

Также в исключения можно внести путь к диску с бекапом (он ведь у вас есть, верно? ;), подмонтированные сетевые шары и прочее.

Финиш

Проверка

Если всё было сделано правильно (и в системе не водилось осиротевших файлов) — команда не должна ничего вывести.

Полный код скрипта

Надеюсь, статья окажется полезной. Рекомендую ближе ознакомиться с синтаксисом этой команды: она ведь намного мощнее чем вы думаете 🙂
Напоследок приведу полный код скрипта для смены UID&GID пользователя и его файлов:

Источник

Traditional Unix permissions и Access Control Lists

«The term user is used in two different ways. We often speak of a logged-in person as a user, and, sometimes, use the term to refer to the process which the user is controlling from his terminal. Especially in the context of user control, however, we apply the term user to any member of the set of users (in the first sense) who could log in. In other words, we speak of a user as a registered identity.»
Multics System Administrators Manual
January 9, 1973
This manual was written by Thomas H. Van Vleck of the Programming Development Office of the Massachusetts Institute of Technology.

Введение

Насколько я понял из чтения Multics Features, а также и другого материала по системам Multics/Unix, именно в Multics, предшественнике Unix, уже присутствовала древовидная иерархическая файловая система в виде каталогов с файлами (называемыми в Multics сегментами), а также
использовались развитые ACLs и режимы доступа в виде rwx-записей для чтения, записи и выполнения. Так что не удивительно, что один из разработчиков Multics, Кен Томпсон (Ken Thompson), перенёс эти идеи в свою новую однопользовательскую операционную систему Unics (в дальнейшем Unix), упростив их до приемлемого уровня. Необходимо вспомнить, что ОС Multics изначально разрабатывалась для работы на серьёзных многопользовательских составных сложных (MULTiplex Information and Computing Service) системах, тогда как Unics писалась в виде баловства для работы на слабом устаревшем компьютере PDP-7, пылившемся в углу.

Впоследствии еще один исследователь лаборатории Bell Labs, Брайан Керниган (Brian Kernighan), как-то в шутку назвал эту систему UNICS (UNiplexed Information and Computing Service — примитивная информационная и вычислительная служба).
Танненбаум. Современные Операционные Системы. 4-е издание.

В мире Unix всё является файлом

Всё в Unix/Linux/POSIX-системе является файлом. Процесс, любое устройство, жёсткий диск, раздел на жёстком диске, etc. Даже каталог, содержащий в себе файлы, является не более чем файлом, в котором перечислены имена жёстких ссылок на другие файлы. Файл определяется номером в inode и не имеет имени. Именем файла является, по минимуму, одна жёсткая ссылка на файл, указанная в файле-каталоге.

Все файлы представлены в файловой системе Операционной Системы (ОС) в виде древовидной структуры, называемой Деревом Каталогов.

UID, GID

Каждый файл в Дереве Каталогов принадлежит определённому пользователю и определённой группе пользователей. Эта информация записывается в область метаданных файла и представлена там полями UID и GID, с числовым значением от 0 до 32767 в ранних Unix, от 0 до 65535 в Linux. Аббревиатура UID и GID означает User ID и Group ID. Подавляющее большинство файлов, созданных на момент установки ОС, имеют UID=0 и GID=0, то есть принадлежат пользователю root и группе root. Видимо по причине того, что установка новой системы происходит из-под рута.

При попытке программой-процессом получить доступ к какому-либо файлу через соответствующий системный вызов, ядром системы производится сравнение UID и GID процесса с UID и GID требуемого файла. При совпадении значений процессу представляется доступ (чтение, запись, исполнение) к файлу в соответствии с установленными флагами прав доступа. Подробнее этот алгоритм проверки разобран ниже.

Получение пользователем UID и GID

Системный администратор первых Unix добавлял в систему новых пользователей ручным редактирование файла /etc/passwd (Из седьмой редакции UNIX PROGRAMMER’S MANUAL, январь 1979):

> Install new users by editing the password file /etc/passwd (passwd(5)). This procedure should be done once multi-user mode is entered (see init(8)). You’ll have to make a current directory for each new user and change its owner to the newly installed name. Login as each user to make sure the password file is correctly edited. For example:

This will make a new login entry for joe, who should be encouraged to use passwd(1) to give himself a password. His default current directory is` /usr/joe` which has been created. The delivered password file has the user *bin* in it to be used as a prototype.

Видно, что пользователю joe назначен UID = 10 и GID = 1. Далее видно, что системному администратору предписывалось создать домашнюю папку нового пользователя и проверить корректность введённых сведений простым входом под логином нового пользователя.

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

После установления связи с Unix, начиналась процедура входа в систему:

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

Интересно, что «The easiest way to log out is» было «to hang up the phone.» Мы уже давно не вешаем трубку для разрыва соединения и посылки соответствующего сигнала процессам. Трубка, которую можно повесить, исчезла, а сигнал остался.

Флаги прав доступа к файлу

Судя по первой редакции UNIX PROGRAMMER’S MANUAL. K. Thompson, D. M. Ritchie. November 3, 1971, в частности File formats, изначально в Unix для файла предусматривались только следующие флаги доступа:

В четвёртой редакции от ноября 1973 года UNIX PROGRAMMER’S MANUAL, Fourth Edition, появились группы пользователей и биты прав доступа к файлу стали более привычными:

В шестой редакции упомянут Sticky бит. А в седьмой редакции от января 1979 года UNIX PROGRAMMER’S MANUAL. Seventh Edition, Volume 1. January, 1979 команда chmod стала такой, какой мы знаем её сейчас.

Где хранятся UID, GID файла и биты прав доступа

При создании файловой системы, кроме места хранения файлов с данными, выделяется место для хранения метаданных о файлах. Метаданные файла представлены структурой, которая называется inode (индексный узел). В inode хранится информация о файле, например:

В 2002 году в ядро Linux была добавлена поддержка Access Control Lists, которая добавила больше гибкости к управлению доступа к файлам, что приблизило Linux 2000-x к Multics 1960-x. Если ранее доступ к файлу назначался только одному пользователю и одной группе пользователей, то теперь появилась возможность назначать доступ к файлу нескольким пользователям и группам.

Сравнение Traditional Unix Permissions vs ACL

Традиционные права доступа Unix, в отличии от ACL, доступны в ФС любой *nix-системы по умолчанию. Несмотря на то, что Traditional Unix Permissions, по сравнению с ACL, довольно примитивны, их достаточно для работы подавляющего большинства систем. Лично я применял ACL на тех серверах, точнее, на тех томах, к информации на которых необходимо было обеспечить доступ некоторого количества пользователей, объединённых в несколько групп с различными правами доступа. Вдобавок к этому могу вспомнить ещё несколько случаев, где мне понадобилась поддержка ACL. На тысяче других систем, мне ACL не понадобилась.

Для некоторых файловых систем (ext3, ext4), при монтировании необходимо вручную включать поддержку ACL. В других (xfs, btrfs), поддержка ACL включена по умолчанию, но её можно отключить при монтировании.

При использовании ACL надо держать в уме, что при некоторых файловых операциях можно потерять эти настройки. Например:

Совместная работа Traditional Unix Permissions & ACL

Алгоритм проверки прав пользователя при обращении к файлу

При системном вызове будут произведены проверки:

После определения принадлежности, соответствующие биты режима доступа разрешают, что может сделать процесс с файлом, то есть чтение, запись, выполнение.

Алгоритм проверки доступа к файлу, защищённого ACL описан в man 5 acl и отличается от вышеприведённого только проверкой маски, которая определяет максимальный уровень прав для всех, кроме владельца.

Команды для работы с традиционными правами доступа Unix

chgrp — редко используемая мной команда для изменения только группы файла.

chmod — изменение прав доступа для владельца, группы файла, а также для остальных. Кроме того, chmod используется для установки SETUID, SETGID И STICKY атрибутов на файлы и каталоги.

umask — команда для установки прав по умолчанию при создании новых файлов и каталогов.

Команды для работы с ACL

getfacl — команда для вывода текущих настроек ACL.

setfacl — команда для установки ACL.

Источник