Letysite.ru

IT Новости с интернет пространства
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Sticky bit linux что это

/привет/мир/etc

Периодические заметки о программировании

пятница, 12 сентября 2014 г.

Linux. Упражнения с set(u|g)id и sticky bit

В прошлый раз я исследовал на практике, как работают разрешения rwx в Linux. Сегодня я продолжу упражнения с правами доступа к файлам и каталогам в Linux и рассмотрю атрибуты setuid , setgid и sticky bit . (Забегая вперед, скажу, что приключение оказалось интереснее, чем я ожидал.) Все приводимые далее примеры я буду выполнять в консоли Ubuntu 14.04.

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

Увидеть эти атрибуты процессов позволяет команда ps :

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

  • setuid — сделать эффективным пользователем процесса владельца исполняемого файла, и
  • setgid — сделать эффективной группой процесса группу исполняемого файла.

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

Классический пример использования setuid — утилита passwd , которая, при изменении каждым пользователем своего пароля, вносит изменения в файл /etc/passwd , доступный для записи только root :

Повторю: каждый пользователь, изменяя свой пароль, вносит изменения в файл, недоступный ему для записи!

Для того, чтобы утилита passwd могла изменять файл /etc/passwd , процесс passwd выполняется с правами эффективного пользователя — владельца исполняемого файла, а этим владельцем является root :

Буква s в триаде user означает установленный атрибут setuid . Помимо passwd , имеются и другие файлы с установленным setuid . Вот некоторые из них:

В /usr/bin имеются также файлы с установленным setgid :

Назначение атрибутов setuid и setgid — дать возможность программе выполнять операции с файлами или каталогами, недоступные запускающему (реальному) пользователю. Отсюда — повышенное внимание к таким исполняемым файлам с точки зрения безопасности. Так, каждый из файлов, принадлежащих root , у которых установлен setuid , выполняется с эффективными правами root !

Что если бы setuid был установлен у файла /bin/rm ?

А если бы в системе отыскался файл, принадлежащий root , с правами доступа -rwsrwxrwx ?

В качестве эксперимента с setuid напишу скрипт come2party для самозаписи пользователей на некое мероприятие. Файл с записями будет доступен для изменения только пользователю-владельцу скрипта — чтобы никто не мог вычеркнуть другого записавшегося.

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

Теперь создам скрипт и установлю необходимые разрешения:

Атрибуты setuid , setgid и sticky bit кодируются 4-ой справа цифрой в восьмеричном представлении разрешений: 4 — setuid , 2 — setgid , 1 — sticky bit . В статье Linux. Упражнения с rwx мы уже встречались с четырехразрядным восьмеричным представлением разрешений — когда воспользовались командой umask .

Запишусь на вечеринку первым!

Теперь пусть запишется пользователь andrey :

Неудача! Проверяю, что скрипт come2party имеет установленный атрибут setuid :

Оказывается, в Linux (и некоторых других ОС семейства Unix) атрибуты setuid и setgid для shell-скриптов не работают! Это ограничение связано с обеспечением безопасности.

На самом деле, скрипт come2party , как и любой shell-скрипт, выполняется программой-интерпретатором /bin/sh или иной, указанной в первой строке скрипта. Процесс, интерпретирующий скрипт, создается из двоичного исполняемого файла /bin/sh (или иного), который не имеет установленных setuid или setgid и потому выполняется с правами запускающего пользователя:

«Несамостоятельность» выполнения скрипта /home/ay/come2party можно наглядно увидеть, если добавить в скрипт команду ps , отображающую выполняемую командную строку. Добавив команду ps , посмотрю на результат как пользователь andrey :

Из вывода команды ps видно, что

  1. скрипт /home/ay/come2party передан в качестве параметра интерпретатору /bin/sh ,
  2. процесс выполняется с эффективными пользователем и группой, равными текущему пользователю и его первичной группе.

(Можно также заметить, что порожденный процессом 3401 процесс 3402 , исполняющий команду ps , унаследовал эффективных пользователя и группу процесса-родителя.)

Чтобы реализовать задуманный сценарий с самозаписью пользователей на вечеринку, мне нужен бинарный исполняемый файл come2party с установленным setuid . Что же касается текстовых файлов, содержащих интерпретируемые скрипты (bash, python, perl и другие), то для них setuid и setgid Linux не поддерживает.

Вместо создания собственного бинарника я решил проделать следующий трюк под пользователем ay :

  1. скопировать /bin/bash в домашний каталог,
  2. установить для /home/ay/bash атрибут setuid и
  3. прописать /home/ay/bash в первой строке скрипта come2party .

Тогда скрипт come2party будет выполняться интерпретатором /home/ay/bash с эффективным пользователем ay , который сможет перенаправить вывод команды echo в файл come2party.lst !

Очищу come2party.lst и запишусь первым:

Теперь пусть запишется пользователь andrey :

Но этого не может быть: интерпретатор /home/ay/bash , скрипт come2party и файл come2party.lst принадлежат ay , и интепретатор выполняет скрипт с эффективными правами пользователя ay ! Проверю, так ли это, выполнив команду ps при помощи домашнего bash :

Как видим, bash и порожденный им процесс ps выполняются с эффективными пользователем и группой andrey .

Получается, что атрибут setuid не работает с bash ? Или вмешивается selinux ?

Google помог установить истину: виноват bash . Оказывается, если реальный пользователь и эффективный пользователь запущенного процесса bash оказываются разными, bash принудительно устанавливает эффективного пользователя равным реальному. Аналогично он поступает и с эффективной группой процесса — ради безопасности и исключения злоупотреблений.

Однако, выход имеется. Ключ -p позволяет отключить параноидальное поведение bash и добиться желаемого:

Пусть теперь пользователь ay изменит первую строчку скрипта /home/ay/come2party , чтобы интерпретатор запускался с ключом -p . Скрипт станет таким:

Теперь andrey сможет, наконец, записаться на вечеринку:

Итак, мне удалось заставить setuid работать с копией интерпретатора bash , принадлежащей пользователю ay . Но возможности bash широки, и пользователь andrey может теперь не только записаться на вечеринку, но и многое другое. Например, удалить файлы, принадлежащие ay :

Очевидно, что bash с setuid чертовски опасен для его владельца. Теперь я убежден, что setuid не стоит раздавать каким угодно исполняемым файлам.

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

На этом я завершу эксперименты с setuid для файлов, сделаю перерыв на кофе, и перейду к каталогам.

Из двух атрибутов setuid и setgid для каталогов в Linux используется только setgid .

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

Такое поведение позволяет организовать совместную работу пользователей над общими файлами в каталоге, при условии, что все эти пользователи — члены группы-владельца каталога. Тогда все созданные в каталоге файлы доступны всем членам группы.

Поставлю эксперимент. Для начала, создам нового пользователя ya , новую группу ayya и добавлю в нее пользователей ay и ya .

Группа ayya является вторичной группой (secondary group) для пользователей ay и ya , а их первичные группы — персональные группы ay и ya , соответственно. Вторичные группы используются только для получения доступа к существующим файлам и каталогам. Тогда как первичная группа устанавливается в качестве группы-владельца созданных пользователем файлов и каталогов.

Создам каталог, для которого установлю группу ayya , полные разрешения для группы и атрибут setgid .

Создам файл в этом каталоге как пользователь ay :

А теперь, как пользователь ya , создам там же другой файл и изменю файл, созданный пользователем ay :

Как видим, созданные в каталоге

ay/shared файлы наследуют группу-владельца от каталога и доступны членам этой группы для изменения. setgid для каталога работает согласно теории!

Наконец, последний предмет для экспериментирования сегодня — атрибут sticky bit .

Как рассказывает Википедия, когда-то в ОС семейства Unix «липкий бит» использовался для удержания кода исполняемых файлов в свопе — для их быстрого повторного запуска. Но эта практика осталась в прошлом, и в Linux данный атрибут используется только с каталогами.

В Linux установленный для каталога sticky bit запрещает удаление и переименование файлов в этом каталоге всем, кроме root , владельца каталога и владельцев соответствующих файлов. Этот запрет работает независимо от разрешений каталога и имеет приоритет над ними.

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

Поставлю эксперимент, дав всем пользователям полный доступ в каталог /home/ay/dummy :

Читать еще:  Команда passwd linux

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

Теперь установлю на /home/ay/dummy атрибут sticky bit :

Пользователи andrey и ya снова создадут файлы в этом каталоге и ya попытается удалить чужой файл:

Не получается! Так работает sticky bit .

Теперь удалю файлы как владелец каталога:

Кстати, сценарий самозаписи на вечеринку можно реализовать с помощью каталога с установленным «липким» битом. Для записи на вечеринку пользователи будут создавать файл с именем пользователя в таком каталоге. Другие пользователи не смогут удалить чужие файлы из этого каталога, а значит, не смогут «вычеркнуть» записавшихся ранее. Такое решение позволяет обойтись без использования setuid (и не требует создания бинарного файла специально для этого случая).

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

♀️ StickyBit, SUID и SGID в Linux с примерами

В этой статье мы расскажем о специальных разрешениях, которые работают с файлами и каталогами, которые называются Stickybit, SUID и SGID.

Sticky работает только для каталогов.

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

Разрешение на запись в каталог дает пользователю право создавать файл, а также право удалять его.

Каталог /tmp — это каталог для временных файлов / каталогов.

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

Но так как пользователи имеют разрешение на запись в этот каталог, они могут удалить любой файл в этом каталоге.

Разрешения этого файла не влияют на удаление.

Но с установленным в каталоге стики битом любой может создать в нем файл / каталог, но может удалить только свои собственные файлы.

Файлы, принадлежащие другим пользователям, не могут быть удалены.

stickybit — Как просмотреть и установить

Вы можете заметить, что тег t добавлен в каталог /tmp, и это означает, что для этого каталога установлен бит.

В Linux стики бит может быть установлен командой chmod.

Вы можете использовать тег + t, чтобы добавить, и тег -t, чтобы удалить бит.

Примечание. В ОС Unix stickybit имеет другое назначение, но мы не обсуждаем его здесь.

Что такое SUID бит и как его установить

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

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

Бит SUID, также известный как бит установки идентификатора пользователя, перезаписывает это поведение.

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

У команды passwd в Linux установлен бит SUID.

Это можно увидеть в третьем поле прав доступа. ‘S’ вместо ‘x’ указывает, что установлен бит SUID.

С установленным битом SUID, когда обычный пользователь (скажем, student) запускает команду passwd, команда запускается с владельцем «root», а не с учетной записью student, поскольку root является владельцем этого файла.

Это необходимо, потому что пароли хранятся в файле /etc/shadow, который не имеет разрешения на групповом или другом уровне.

Вы должны понимать, что все пользователи не могут получить разрешение на чтение или запись этого файла по соображениям безопасности; в противном случае они будут читать / изменять пароли других пользователей.

Таким образом, это вызывает проблему: если у пользователей нет прав доступа к этому файлу, как они будут изменять свои собственные пароли?

SUID немного решает проблему.

У команды passwd установлен бит SUID, поэтому, когда обычные пользователи выполняют эту команду, они запускают ее под владельцем root, то есть владельцем команды passwd.

Как установить и сбросить бит SUID

Следует отметить, что бит SUID работает только с файлами.

Чтобы установить бит SUID на файл, используйте команду chmod следующим образом

Числовой метод для изменения разрешений также может быть использован.

Предположим, что если обычные разрешения для файла равны 744, то с установленным битом SUID они станут 4744.

Бит SUID имеет значение 4.

Как SGID Bit работает с файлами и каталогоми

В отличие от бита SUID, бит SGID работает как с файлами, так и с каталогами, но в обоих случаях он имеет различное значение.

По файлам:

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

Например, файл /sbin/netreport имеет установленный бит SGID, который можно увидеть в «s» вместо «x» в разрешениях группы.

Этот файл имеет групповое владение группой root.

Таким образом, когда пользователь (скажем, student) выполняет его, соответствующий процесс не будет принадлежать группе student, а будет принадлежать группе root.

По каталогам:

Теперь поговорим о SGID в каталогах.

SGID для каталогов используется для создания совместных каталогов.

Чтобы понять бит SGID для каталогов, рассмотрим следующий сценарий:

Предположим, что три пользователя Джек, Джонс и Дженни вместе работают над каким-то проектом.

Все они принадлежат к группе под названием javaproject.

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

Все они должны видеть файлы друг друга.

Это можно сделать, просто предоставив разрешение на чтение на уровне группы.

Далее, предположим, что каталогом, используемым для проекта, является «/javaproject».

Здесь возникает проблема: когда файл создается, он принадлежит к основной группе пользователя, создавшего файл.

Таким образом, когда разные пользователи создают свои файлы в этом каталоге, эти файлы не будут принадлежать группе javaproject group.

Что мы делаем для решения нашей проблемы, так это то, что мы устанавливаем группу каталога /javaproject равной группе javaproject, и устанавливаем бит SGID.

Когда в каталоге установлен бит SGID, все файлы и каталоги, созданные в нем, имеют групповое владение группой, связанной с этим каталогом.

Это означает, что после установки бита SGID в каталоге /javaproject все файлы и каталоги, создаваемые в этом каталоге, будут принадлежать группе «javaproject».

Более того, это поведение является рекурсивным, то есть в каталогах, созданных в этом каталоге, также будет установлен бит SGID.

Права у нового каталога также будут такими же, как и у каталога /javaproject.

Бит SGID может быть установлен командой chmod следующим образом:

Теперь, когда пользователь jones создает файл в этом каталоге, он создается под владельцем группы javaproject.

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

Права доступа к файлам в Linux

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

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

Основные права доступа к файлам в Linux

Изначально каждый файл имел три параметра доступа. Вот они:

  • Чтение — разрешает получать содержимое файла, но на запись нет. Для каталога позволяет получить список файлов и каталогов, расположенных в нем;
  • Запись — разрешает записывать новые данные в файл или изменять существующие, а также позволяет создавать и изменять файлы и каталоги;
  • Выполнение — вы не можете выполнить программу, если у нее нет флага выполнения. Этот атрибут устанавливается для всех программ и скриптов, именно с помощью него система может понять, что этот файл нужно запускать как программу.

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

  • Владелец — набор прав для владельца файла, пользователя, который его создал или сейчас установлен его владельцем. Обычно владелец имеет все права, чтение, запись и выполнение.
  • Группа — любая группа пользователей, существующая в системе и привязанная к файлу. Но это может быть только одна группа и обычно это группа владельца, хотя для файла можно назначить и другую группу.
  • Остальные — все пользователи, кроме владельца и пользователей, входящих в группу файла.
Читать еще:  Linux install command

Именно с помощью этих наборов полномочий устанавливаются права файлов в linux. Каждый пользователь может получить полный доступ только к файлам, владельцем которых он является или к тем, доступ к которым ему разрешен. Только пользователь Root может работать со всеми файлами независимо от их набора их полномочий.

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

Специальные права доступа к файлам в Linux

Для того, чтобы позволить обычным пользователям выполнять программы от имени суперпользователя без знания его пароля была придумана такая вещь, как SUID и SGID биты. Рассмотрим эти полномочия подробнее.

  • SUID — если этот бит установлен, то при выполнении программы, id пользователя, от которого она запущена заменяется на id владельца файла. Фактически, это позволяет обычным пользователям запускать программы от имени суперпользователя;
  • SGID — этот флаг работает аналогичным образом, только разница в том, что пользователь считается членом группы, с которой связан файл, а не групп, к которым он действительно принадлежит. Если SGID флаг установлен на каталог, все файлы, созданные в нем, будут связаны с группой каталога, а не пользователя. Такое поведение используется для организации общих папок;
  • Sticky-bit — этот бит тоже используется для создания общих папок. Если он установлен, то пользователи могут только создавать, читать и выполнять файлы, но не могут удалять файлы, принадлежащие другим пользователям.

Теперь давайте рассмотрим как посмотреть и изменить права на файлы в linux.

Как посмотреть права доступа к файлам в Linux

Конечно, вы можете посмотреть права доступа к файлам в Linux с помощью файлового менеджера. Все они поддерживают эту функцию, но так вы получите неполную информацию. Для максимально подробной информации обо всех флагах, в том числе специальных, нужно использовать команду ls с параметром -l. Все файлы из каталога будут выведены в виде списка, и там будут показаны все атрибуты и биты.

Чтобы узнать права на файл linux выполните такую команду, в папке где находится этот файл:

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

Рассмотрим подробнее, что значат условные значения флагов прав:

  • — нет прав, совсем;
  • —x — разрешено только выполнение файла, как программы но не изменение и не чтение;
  • -w- — разрешена только запись и изменение файла;
  • -wx — разрешено изменение и выполнение, но в случае с каталогом, вы не можете посмотреть его содержимое;
  • r— — права только на чтение;
  • r-x — только чтение и выполнение, без права на запись;
  • rw- — права на чтение и запись, но без выполнения;
  • rwx — все права;
  • —s — установлен SUID или SGID бит, первый отображается в поле для владельца, второй для группы;
  • —t — установлен sticky-bit, а значит пользователи не могут удалить этот файл.

В нашем примере, файл test1 имеет типичные разрешения для программ, владелец может все, группа только чтение и выполнение, а все остальные — только выполнение. Для test2 дополнительно установлен флаг SUID и SGID. А для папки test3 установлен Sticky-bit. Файл test4 доступный всем. Теперь вы знаете как посмотреть права на файл linux.

Как изменить права файла в Linux

Чтобы изменить права на файл в linux вы можете использовать утилиту chmod. Она позволяет менять все флаги, включая специальные. Рассмотрим ее синтаксис:

$ chmod опции категория действие флаг файл

Опции сейчас нас интересовать не будут, разве что только одна. С помощью опции -R вы можете заставить программу применять изменения ко всем файлам и каталогам рекурсивно.

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

  • u — владелец файла;
  • g — группа файла;
  • o — другие пользователи.

Действие может быть одно из двух, либо добавить флаг «+», либо убрать флаг — «-«. Что касается самих прав доступа, то они аналогичны выводу утилиты ls: r — чтение, w — запись, x — выполнение, s — suid/sgid, в зависимости от категории, для которой вы его устанавливаете, t — устанавливает sticky-bit. Например, всем пользователям полный доступ к файлу test5:

chmod ugo+rwx test5

Или заберем все права у группы и остальных пользователей:

chmod go-rwx test5

Дадим группе право на чтение и выполнение:

chmod g+rx test5

Остальным пользователям только чтение:

Для файла test6 установим SUID:

А для test7 — SGID:

Посмотрим что получилось:

Как видите, изменить права на файл в linux очень просто. К тому же вы можете изменить основные права с помощью файлового менеджера.

Выводы

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

На завершение хочу предложить неплохое видео про права доступа в linux:

Нет похожих записей

Оцените статью:

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux интересуюсь всем, что связано с информационными технологиями и современной наукой.

4 комментария

перестали приходить на почту обновления.

Ты сам виноват сам какую нибудь ошибку допустил! У меня все в норме.

Спасибо! Особенно на ссылку на обучающее видео.

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

Sticky bit

Sticky bit — дополнительный атрибут файлов или директорий в операционных системах семейства UNIX.

Содержание

История

Впервые sticky bit появился в пятой редакции UNIX в 1974 году для использования в исполняемых файлах. Он применялся для уменьшения времени загрузки наиболее часто используемых программ. После закрытия программы код и данные оставались в памяти, а следующий запуск происходил быстрее.

Использование

Сегодня sticky bit используется в основном для директорий, чтобы защитить в них файлы. Из такой директории пользователь может удалить только те файлы, владельцем которых он является. Примером может служить директория /tmp, в которой запись открыта для всех пользователей, но нежелательно удаление чужих файлов. Установка атрибута производится утилитой chmod.

В операционной системе Solaris для файлов, не являющихся программами, имеет строго противоположное действие — запрещает сохранение данных этого файла в системном кэше.

Примеры

chmod 1xxx <имяфайла>, где xxx права на файл.

См. также

Примечания

Литература

  • Робачевский А. Н., Немнюгин С. А., Стесик О. Л. Глава 1. Работа в операционной системе UNIX // Операционная система UNIX. — 2-е изд. — СПб. : БХВ-Петербург, 2008. — С. 40–43. — 656 с. — ISBN 978-5-94157-538-1

Ссылки

  • chmod(1) — страница справки man по пользовательским командам GNU/Linux (англ.)

Wikimedia Foundation . 2010 .

Смотреть что такое «Sticky bit» в других словарях:

Sticky Bit — Das Sticky Bit (auch t Bit oder Save Text Bit) ist ein erweitertes Dateirecht, d. h. ein Dateiattribut unter Unix. Es wirkt sich auf Verzeichnisse und Dateien unterschiedlich aus. Inhaltsverzeichnis 1 Notation 2 Wirkung 2.1 Bei au … Deutsch Wikipedia

Sticky bit — Das Sticky Bit (auch t Bit oder Save Text Bit) ist ein erweitertes Dateirecht, d. h. ein Dateiattribut unter Unix. Es wirkt sich auf Verzeichnisse und Dateien unterschiedlich aus. Inhaltsverzeichnis 1 Notation 2 Wirkung 2.1 Bei ausführbaren… … Deutsch Wikipedia

Sticky bit — Este artículo o sección necesita referencias que aparezcan en una publicación acreditada, como revistas especializadas, monografías, prensa diaria o páginas de Internet fidedignas. Puedes añadirlas así o avisar … Wikipedia Español

Sticky bit — The sticky bit is an access right flag that can be assigned to files and directories on Unix systems.HistoryThe sticky bit was introduced in the Fifth Edition of Unix in 1974 for use with pure executable files. When set, it instructed the… … Wikipedia

Читать еще:  Декодер h 264 linux

sticky bit — noun a) A fault in a digital circuit, where a signal does not change as expected, but remains always in one state. b) A bit in an inode indicating that an executable program should be kept in memory after it terminates … Wiktionary

Sticky — Stickiness or the quality of being sticky can refer to several things: * the physical phenomena of adhesion and cohesion * the defining physico chemical property of glue * Sticky (economics) * Sticky (comics) * Sticky content on the Web attracts… … Wikipedia

Sticky bomb — For other uses, see Sticky bomb (disambiguation). Sticky bomb Close up view of sticky bombs being manufactured Type Anti tank hand grenade Place … Wikipedia

sticky — (1) A term used by economists to describe changes in dependent variables that tend to lag behind changes in the independent variables with which they are associated. For example, time lags are known to exist between changes in prevailing interest … Financial and business terms

sticky wicket — noun : a difficult or delicate problem or situation * * * 1. Cricket. the area of ground around a wicket when it is tacky because of recent rain and therefore does not allow the ball to bounce well. 2. Chiefly Brit. a situation requiring delicate … Useful english dictionary

X-Bit — Unter Unix Dateirechten versteht man bei Unix Derivaten wie Linux und Mac OS X eine der ersten Implementierung von Dateiberechtigungen, die es bereits in der ersten Version Anfang der 1970er Jahre des AT T Unix gab. Diese Dateirechte zeichnen… … Deutsch Wikipedia

Sticky Bit, SUID and SGID in Linux with Examples

In this article, we explain special permissions that work on files and directories named as Sticky bit, SUID and SGID.

The sticky bit works on directories only. If a user wants to create or delete a file/directory in some directory, he needs write permission on that directory. The write permission on a directory gives a user the privilege to create a file as well as the privilege to remove it.

The /tmp directory is the directory for temporary files/directories. This directory has all the rights on all the three levels because all the users need to create/delete their temporary files. But as the users have write permission on this directory, they can delete any file in this directory. The permissions of that file do not have any effect on deletion.

But with sticky bit set on a directory, anyone can create a file/directory in it, but can delete his own files only. Files owned by other users cannot be deleted.

Sticky bit — How to view and set

You could notice t tag added to /tmp directory and it means bit is set for this directory.

In Linux sticky bit can be set with chmod command. You can use +t tag to add and -t tag to delete sticky bit.

Note: In Unix flavored OS, sticky bit has a different purpose but we are not discussing it here.

What is SUID Bit and How to set it

When an executable file runs, it runs under the ownership of the user who has executed it. It means that when student user runs ls command, then the corresponding process will run under the ownership of student. The SUID bit, also known as Set User ID bit, overwrites this behavior. If SUID bit is set on a program, then that program will run as the owner of that file, irrespective of who is executing it.

The passwd command in Linux has SUID bit set.

This can be seen in the third field of permissions. The ‘s’ in place of ‘x’ indicates that SUID bit is set. With SUID bit set, when a normal user (say student) runs the passwd command, the command runs with the ownership of ‘root’, and not as student, because root is the owner of this file. This behavior is required because the passwords are stored in the /etc/shadow file, which has no permission on group or other level.

You need to understand that all users cannot be given read or write permission on this file for security reasons; otherwise, they will read/change the passwords of other users. So this causes a problem that if the users don’t have permission on this file, then how will they change their own passwords? So SUID bit solves the problem. The passwd command has SUID bit set, so when normal users execute this command, they run it with the ownership of root, i.e. the owner of passwd command.

How to Set and unset SUID bit

This is to be noted that SUID bit works on files only. To set the SUID bit on a file, use the chmod command as follows

The numeric method for changing permissions can also be used. Suppose if the normal permissions for a file are 744, then with SUID bit set, these will become 4744. SUID bit has value 4.

How SGID Bit work on file and directory

Unlike SUID bit, SGID bit works on both files and directories, but it has a different meaning in both cases.

On files:

For file, it has similar meaning as the SUID bit, i.e. when any user executes a file with SGID bit set on it, it will always be executed with the group ownership of that file, irrespective of who is running it. For example, the file /sbin/netreport has SGID bit set, which can be seen in the ‘s’ instead of ‘x’ in group permissions.

This file has group ownership of root group. So when a user (say student) executes it, then the corresponding process will not have group ownership of student, but that of root group.

On directories:

Now let’s talk about SGID on directories. SGID on directories is used for creating collaborative directories. To understand SGID bit on directories, consider the following scenario:

Suppose three users jack, jones and jenny are working together on some project. All of them belong to a group named javaproject. For the course of the project, they need to share all the files related to the project. All of them must be able to see each other’s file. This can be done simply by providing read permission on group level. Further, suppose that the directory used for the project is «/javaproject».

Here, a problem arises that when a file is created, it belongs to the primary group of the user who created the file. So, when different users create their files in this directory, those files will not have group ownership of javaproject group.

What we do for our problem is that we set the group of /javaproject directory to be javaproject group, and set the SGID bit set on it. When SGID bit is set on a directory, all the files and directory created within it has the group ownership of the group associated with that directory. It means that after setting SGID bit on /javaproject directory, all the files and directories being created in this directory will have the group ownership of «javaproject» group. Moreover, this behavior is recursive, i.e. the directories created in this directory will have SGID bit set as well. The permissions for the new directory will also be same as that of /javaproject directory.

The SGID bit can be set with chmod command as follows:

Now when jones user creates a file in this directory, it is created under the group ownership of javaproject group.

The numeric value corresponding to SGID bit is 2. So to add SGID bit numerically, use the following command:

Thanks for reading this article and refer sticky bit wiki page as well.

Ссылка на основную публикацию
Adblock
detector