Почему uid пользователя задается больше 1000

When did user accounts using UIDs above 1000 become normal? And why?

According the UNIX and Linux System Administration Handbook (5th Edition) the idea behind starting UIDs at 1000 is to provide plenty of room for nonhuman users that might get added in the future.

You must log in to answer this question.

The Overflow Blog

Linked

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Глубокое погружение в Linux namespaces, часть 2

В предыдущей части мы только окунули пальцы ног в воды namespace и при этом увидели, как это было просто — запустить процесс в изолированном UTS namespace. В этом посте мы осветим User namespace.

Среди прочих ресурсов, связанных с безопасностью, User namespaces изолирует идентификаторы пользователей и групп в системе. В этом посте мы сосредоточимся исключительно на ресурсах user и group ID (UID и GID соответственно), поскольку они играют фундаментальную роль в проведении проверок разрешений и других действий во всей системе, связанных с безопасностью.

В Linux эти ID — просто целые числа, которые идентифицируют пользователей и группы в системе. И каждому процессу назначаются какие-то из них, чтобы задать к каким операциями/ресурсам этот процесс может и не может получить доступ. Способность процесса нанести ущерб зависит от разрешений, связанных с назначенными ID.

User Namespaces

User namespace имеет собственную копию пользовательского и группового идентификаторов. Затем изолирование позволяет связать процесс с другим набором ID — в зависимости от user namespace, которому он принадлежит в данный момент. Например, процесс $pid может выполняться от root (UID 0) в user namespace P и внезапно продолжает выполняться от proxy (UID 13) после переключения в другой user namespace Q.

User spaces могут быть вложенными! Это означает, что экземпляр пользовательского namespace (родительский) может иметь ноль и больше дочерних пространств имён, и каждое дочернее пространство имён может, в свою очередь, иметь свои собственные дочерние пространства имён и так далее… (до достижения предела в 32 уровня вложенности). Когда создаётся новый namespace C, Linux устанавливает текущий User namespace процесса P, создающего C, как родительский для C и это не может быть изменено впоследствии. В результате все user namespaces имеют ровно одного родителя, образуя древовидную структуру пространств имён. И, как и в случае с деревьями, исключение из этого правила находится наверху, где у нас есть корневой (или начальный, дефолтный) namespace. Это, если вы еще не делаете какую-то контейнерную магию, скорее всего user namespace, к которому принадлежат все ваши процессы, поскольку это единственный user namespace с момента запуска системы.

Маппинги User ID

User namespace, по сути, содержит набор идентификаторов и некоторую информацию, связывающую эти ID с набором ID других user namespace — этот дуэт определяет полное представление о ID процессов, доступных в системе. Давайте посмотрим, как это может выглядеть:

В другом окне терминала давайте запустим шелл с помощью unshare (флаг -U создаёт процесс в новом user namespace):

Погодите, кто? Теперь, когда мы находимся во вложенном шелле в C, текущий пользователь становится nobody? Мы могли бы догадаться, что поскольку C является новым user namespace, процесс может иметь иной вид ID. Поэтому мы, возможно, и не ждали, что он останется iffy , но nobody — это не смешно. С другой стороны, это здорово, потому что мы получили изолирование, которое и хотели. Наш процесс теперь имеет другую (хоть и поломанную) подстановку ID в системе — в настоящее время он видит всех, как nobody и каждую группу как nogroup .

Информация, связывающая UID из одного user namespace с другим, называется маппингом user ID. Он представляет из себя таблицы поиска соответствия ID в текущем user namespace для ID в других namespace и каждый user namespace связан ровно одним маппингом UID (в дополнение еще к одному маппингу GID для group ID).

Этот маппинг и есть то, что сломано в нашем unshare шелле. Оказывается, что новые user namespaces начинаются с пустого маппинга, и в результате Linux по умолчанию использует ужасного пользователя nobody . Нам нужно исправить это, прежде чем мы сможем сделать какую-либо полезную работу в нашем новом пространстве имён. Например, в настоящее время системные вызовы (например, setuid ), которые пытаются работать с UID, потерпят неудачу. Но не бойтесь! Верный традиции всё-есть-файл, Linux представляет этот маппинг с помощью файловой системы /proc в /proc/$pid/uid_map (в /proc/$pid/gid_map для GID), где $pid — ID процесса. Мы будем называть эти два файла map-файлами

Map-файлы

Map-файлы — особенные файлы в системе. Чем особенные? Ну, тем, что возвращают разное содержимое всякий раз, когда вы читаете из них, в зависимости от того, какой ваш процесс читает. Например, map-файл /proc/$pid/uid_maps возвращает маппинг от UID’ов из user namespace, которому принадлежит процесс $pid , UID’ам в user namespace читающего процесса. И, как следствие, содержимое, возвращаемое в процесс X, может отличаться от того, что вернулось в процесс Y, даже если они читают один и тот же map файл одновременно.

В частности, процесс X, считывающий UID map-файл /proc/$pid/uid_map , получает набор строк. Каждая строка отображает непрерывный диапазон UID’ов в user namespace C процесса $pid , соответствующий диапазону UID в другом namespace.

Каждая строка имеет формат $fromID $toID $length , где:

$fromID является стартовым UID диапазона для user namespace процесса $pid
$lenght — это длина диапазона.
Трансляция $toID зависит от читающего процесса X. Если X принадлежит другому user namespace U, то $toID — это стартовый UID диапазона в U, который мапится с $fromID . В противном случае $toID — это стартовый UID диапазона в P — родительского user namespace процесса C.

Например, если процесс читает файл /proc/1409/uid_map и среди полученных строк видно 15 22 5 , то UID’ы с 15 по 19 в user namespace процесса 1409 маппятся в UID’ы 22-26 отдельного user namespace читающего процесса.

С другой стороны, если процесс читает из файла /proc/$$/uid_map (или map-файла любого процесса, принадлежащего тому же user namespace, что и читающий процесс) и получает 15 22 5 , то UID’ы c 15 по 19 в user namespace C маппятся в UID’ы c 22 по 26 родительского для C user namespace.

Давайте это попробуем:

Хорошо, это было не очень захватывающе, так как это были два крайних случая, но это говорит там о нескольких вещах:

Вновь созданный user namespace будет фактически иметь пустые map-файлы.
UID 4294967295 не маппится и непригоден для использования даже в root user namespace. Linux использует этот UID специально, чтобы показать отсутствие user ID.

Написание UID Map файлов

Чтобы исправить наш вновь созданный user namespace C, нам просто нужно предоставить наши нужные маппинги, записав их содержимое в map-файлы для любого процесса, который принадлежит C (мы не можем обновить этот файл после записи в него). Запись в этот файл говорит Linux две вещи:

Какие UID’ы доступны для процессов, которые относятся к целевому user namespace C.
Какие UID’s в текущем user namespace соответствуют UID’ам в C.

Например, если мы из родительского user namespace P запишем следующее в map-файл для дочернего пространства имён C:

мы по существу говорим Linux, что:

Что касается процессов в C, единственным UID’ами, которые существуют в системе, являются UID’ы 0 и 3 . Например, системный вызов setuid(9) всегда будет завершаться чем-то вроде недопустимого id пользователя.
UID’ы 1000 и 0 в P соответствуют UID’ам 0 и 3 в C. Например, если процесс, работающий с UID 1000 в P, переключится в C, он обнаружит, что после переключения его UID стал root 0 .

Владелец пространств имён и привилегии

В предыдущем посте мы упомянули, что при создании новых пространств имён требуется доступ с уровнем суперпользователя. User namespaces не налагают этого требования. На самом деле, еще одной их особенностью является то, что они могут владеть другими пространствами имён.

Всякий раз, когда создаётся не user namespace N, Linux назначает текущий user namespace P процесса, создающего N, владельцем namespace N. Если P создан наряду с другими пространствами имён в одном и том же системном вызове clone , Linux гарантирует, что P будет создан первым и назначен владельцем других пространств имён.

Владелец пространств имён важен потому, что процесс, запрашивающий выполнения привилегированного действия над ресурсом, задействованным не user namespace, будет иметь свои UID привилегии, проверенные в отношении владельца этого user namespace, а не корневого user namespace. Например, скажем, что P является родительским user namespace дочернего C, а P и C владеют собственными network namespace M и N соответственно. Процесс может не иметь привилегий для создания сетевых устройств, включенных в M, но может быть в состоянии это делать для N.

Следствием наличия владельца пространств имён для нас является то, что мы можем отбросить требование sudo при выполнении команд с помощью unshare или isolate , если если мы запрашиваем также создание и user namespace. Например, unshare -u bash потребует sudo , но unshare -Uu bash — уже нет:

Как разрешаются ID

Мы только что увидели процесс, запущенный от обычного пользователя 1000 внезапно переключился на root . Не волнуйтесь, никакой эскалации привилегий не было. Помните, что это просто маппинг ID: пока наш процесс думает, что он является пользователем root в системе, Linux знает, что root — в его случае — означает обычный UID 1000 (благодаря нашему маппингу). Так что в то время, когда пространства имён, принадлежащие его новому user namespace (подобно network namespace в C), признают его права в качестве root , другие (как например, network namespace в P) — нет. Поэтому процесс не может делать ничего, что пользователь 1000 не смог бы.

Всякий раз, когда процесс во вложенном user namespace выполняет операцию, требующую проверки разрешений — например, создание файла — его UID в этом user namespace сравнивается с эквивалентным ID пользователя в корневом user namespace путём обхода маппингов в дереве пространств имён до корня. В обратном направлении происходит движение, например, когда он читает ID пользователей, как мы это делаем с помощью ls -l my_file . UID владельца my_file маппится из корневого user namespace до текущего и окончательный соответствующий ID (или nobody, если маппинг отсутствовал где-либо вдоль всего дерева) отдаётся читающему процессу.

Групповые ID

Даже если мы оказались root в C, мы до сих пор ассоциированы с ужасной nogroup в качестве нашего ID группы. Нам просто нужно сделать то же самое для соответствующего /proc/$pid/gid_map . Прежде чем мы сможем это сделать, нам нужно отключить системный вызов setgroups (в этом нет необходимости, если у нашего пользователя уже есть CAP_SETGID capability в P, но мы не будем предполагать этого, поскольку это обычно идёт вместе с привилегиями суперпользователя), написав «deny» в файл proc/$pid/setgroups :

Реализация

Как вы можете видеть, есть много сложностей, связанных с управлением user namespaces, но реализация довольно проста. Всё, что нам нужно сделать, это написать кучу строк в файл — муторно было узнать, что и где писать. Без дальнейших церемоний, вот наши цели:

Клонировать командного процесса в его собственном user namespace.
Написать в UID и GID map-файлы командного процесса.
Сбросить все привилегии суперпользователя перед выполнением команды.

1 достигается простым добавлением флага CLONE_NEWUSER в наш системный вызов clone .

Для 2 мы добавляем функцию prepare_user_ns , которая осторожно представляет одного обычного пользователя 1000 в качестве root .

И вызовем его из основного процесса в родительском user namespace прямо перед тем, как мы подадим сигнал командному процессу.

Для шага 3 мы обновляем функцию cmd_exec , чтобы убедиться, что команда выполняется от обычного непривилегированного пользователя 1000 , которого мы предоставили в маппинге (помните, что root пользователь 0 в user namespace командного процесса — это пользователь 1000 ):

И это всё! isolate теперь запускает процесс в изолированном user namespace.

В этом посте было довольно много подробностей о том, как работают User namespaces, но в конце концов настройка экземпляра была относительно безболезненной. В следующем посте мы рассмотрим возможность запуска команды в своём собственном Mount namespace с помощью isolate (раскрывая тайну, стоящую за инструкцией FROM из Dockerfile ). Там нам потребуется немного больше помочь Linux, чтобы правильно настроить инстанс.

Права, пользователи и прочее в Linux (часть 2)

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

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

Что такое пользователи?

По факту это любой кто использует компьютер. Имя пользователя это как правило его псевдоним, логин, который может состоять из букв Eng алфавита, арабских чисел и нижнего подчеркивания. Использовать можно любое имя кроме root, hal и adm, так как эти имена являются зарезервированными системой именами. Кроме логина в системе может храниться и полное имя реального пользователя, что иногда, при администрировании бывает полезным.

Что имеет каждый пользователь в linux системе?

домашняя папка — для каждого пользователя создается своя домашняя директория в директории /home. Там могут храниться все его личные данные;
командная оболочка — каждый пользователь имеет свою командную оболочку (командный интерпретатор), например /bin/bash, bin/sh и другие. (по умолчанию, как правило, используется /bin/bash)
личный идентификатор (User ID) — каждый пользователь нумеруется, чтобы система могла отслеживать его, ибо она это делает только по uid пользователя
пароль — естественно, каждый пользователь имеет свой пароль, которых храниться в зашифрованном виде (encripted)
группа — и каждый пользователь может находиться в одной или более группе, о них мы поговорим немного подробнее..

Что такое группы?

Чтобы администраторам было проще разделять полномочия между пользователями, в Linux системах существуют группы, поэтому для каждого файла в linux системе определяется не только пользователь но и группа. По факту группы нужны для того, чтобы предоставить одинаковые полномочия на файлы или какие-нибудь действия. И опять же, каждая группа имеет свой уникальный идентификатор — GID (GroupID)

Как узнать, какие пользователи есть в системе?

Информация о пользователях храниться в файле /etc/passwd в виде строк, одна строка — это один пользователь, и эта строка имеет следующий формат:

а расшифровывается она следующим образом:

account — логин пользователя
password — зашифрованный пароль пользователя
UID — id пользователя (uid создается более 1000)
GID — id основной группы (gid создается более 100)
GECOS — дополнительная информация о пользователе (не обязательно)
directory — домашний каталог ($HOME) пользователя
shell — командный интерпретатор пользователя (обычно /bin/sh)

Чтобы посмотреть какие пользователи существуют в системе, достаточно набрать следующую команду:

Ну и никто не запрещает посмотреть активных в данный момент пользователей:

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

При создании пользователя, нужно выполнить ряд следующих действий:

создается запись в /etc/passwd
создается домашний каталог пользователя (/home/username)
устанавливаются необходимые права
назначается необходимая командная оболочка
модифицируются конфигурационные файлы прочих приложений

Чтобы как то упростить жизнь администраторам, существует специальная утилита useradd. Настройки этой утилиты хранятся в файле /etc/default/useradd, в котором можно изменить применяемые новым пользователям параметры по умолчанию.

Чтобы создать нового пользователя lolosh в группе users и lalki достаточно набрать следующую команду:

расшифровывается эта команда следующим образом:

Что означают эти ключи:

m — создаёт домашний каталог, вида /home/[имя пользователя]
-g — имя или номер основной группы пользователя
-G — список дополнительных групп, в которые входит пользователь
-s — определяет командную оболочку пользователя.

Подробнее узнать о том, что умеет эта утилита можно почитать в man страницах.

Добавление и изменение дополнительной информации

Для того, чтобы наделить пользователя дополнительной информацией, можно воспользоваться командой chfn. Рассмотрим что мы можем добавить:

Подробнее, о возможностях этой команды читайте man.

Задаем или изменяем пароль

Для того, чтобы задать пользователю пароль, достаточно воспользоваться следующей командой:

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

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

Так же еще можно установить срок годности учетной записи и многое другое, подробно можно почитать man.

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

Удалить пользователя можно следующей командой:

Обратите внимание, с указанным ключом -r удаляется и его домашняя директория.

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

Тут так же нет ничего сложного. Чтобы просмотреть список существующих групп, достаточно отобразить файл /etc/group:

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