Пользователи в 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.
📑 Команда id — найти UID пользователя или GID
Эта команда полезна для поиска следующей информации:
Цель
Отображает системные идентификаторы указанного пользователя.
синтаксис команды id
По умолчанию команда id показывает имена пользователей и групп и числовые идентификаторы вызывающего процесса, то есть текущего пользователя, который запускает команду id на экране. Если имя пользователя или идентификатор пользователя ([UserNameHere]) указаны в командной строке, отображаются идентификаторы пользователя и группы этого пользователя.
Показать свой собственный UID и GID
Как найти UID конкретного пользователя?
В этом примере найдите UID пользователя vasia, введите:
Как найти GID конкретного пользователя?
В этом примере найдите GID пользователя vasia, запустите:
Как увидеть UID и все группы, связанные с именем пользователя?
В этом примере найдите UID и все группы, связанные с пользователем с именем «root», введите:
Как узнать все группы, к которым принадлежит пользователь…
В этом примере отобразите UID и все группы, связанные (вторичные группы) с пользователем с именем «vasia», запустите:
1000 20 12 61 79 80 81 98 33 100 204 398 399
Отображать имя вместо UID / GID
Как отобразить реальный идентификатор вместо эффективного идентификатора для указанного пользователя?
Параметры команды id
Смотрите также
man id — Страница руководства по команде id
[Пост] Управление доступом в 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 является ли файл исполняемым или нет, определяется не по его расширению, а по правам доступа. Кроме того, эти полномочия указываются отдельно для владельца файла, членов группы файла и для всех остальных.
Кроме указанного представления полномочий доступа (символьного), существует так же и числовое представление. Для общего понимания, приведу таблицу соответствия числового (двоичного и десятичного) значения прав доступа и буквенного:
| владелец | группа | остальные | |
|---|---|---|---|
| буквенное | rwx | r-x | r– |
| двоичное | 111 | 101 | 100 |
| двоичное в десятичных | 421 | 401 | 400 |
| десятичное | 7 | 5 | 4 |
Управление правами доступа
Управление правами доступа происходит с помощью команды 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 без параметров. Пример:
Записки 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 при этом заблокирован, после завершения сеанса в системе не останется ни одного привилегированного пользователя.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Права доступа
Работая с 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 у сценария, поделать он всё равно ничего не сможет.