Исполняемый режим S разрешения используется для чего-нибудь?

Все четыре комбинации существуют и значимы.

"Фактический владелец этого файла может выполнить его?" и, "Кто будет, система притвориться петляет?" два отдельных вопроса. Все четыре комбинации возможны и значимы.

Строки полномочий, отображенные ls -l или stat -c %A шоу, во владельце выполняют положение (т.е. вместо ? в ---?------), четыре различных символа, один для каждой комбинации:

1. - означает, что владелец не может петлять и, если невладелец выполняет его, это работает как тот другой пользователь.
2. x означает, что владелец может петлять и, если невладелец выполняет его, это работает как тот другой пользователь.
3. S означает, что владелец не может петлять и, если невладелец выполняет его, это работает как владелец вместо этого.
4. s означает, что владелец может петлять и, если невладелец выполняет его, это работает как владелец вместо этого.

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

• x или s средство выполнить бит установлено. - или S средства это не.
• s или S означает, что setuid укусил, установлен. - или x средства это не.

Точно так же группа может или не может иметь, выполняют полномочия на файле и, если выполняется, она может или не может быть выполнена с идентификационными данными другой группы, чем тот из пользователя, который выполняет ее. Чтобы заставить файл работать с идентификационными данными группы ее владельца группы, а не того из пользователя, который выполняет его, Вы установили бы бит setgid (------s--- или ------S---).

S не представляет отдельный бит режима. Это - просто способ показать, что setuid (или setgid) бит установлен, но соответствующий исполняемый бит не установлен.

$ touch foo
$ chmod u+S foo
chmod: invalid mode: ‘u+S’
Try 'chmod --help' for more information.

Можно исследовать сами биты.

Чтобы видеть, что это отдельные биты, используйте %a спецификатор формата для stat вместо %A. Для упрощения вещей я сбросил все другие биты режима.

$ touch a b c d
$ chmod u=,g=,o= a
$ chmod u=x,g=,o= b
$ chmod u=s,g=,o= c
$ chmod u=xs,g=,o= d
$ stat -c '%A %n' a b c d
---------- a
---x------ b
---S------ c
---s------ d
$ stat -c '%04a %n' a b c d
0000 a
0100 b
4000 c
4100 d

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

$ stat -c '%a %n' a b c d | perl -pe 's/\d+/sprintf("%012b", oct($&))/e'
000000000000 a
000001000000 b
100000000000 c
100001000000 d

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

Выполните управление битами, может ли попытка петлять успешно выполниться, в то время как setuid/setgid биты управляют, чьи идентификационные данные новый процесс выполняет под тем, если позволяется быть созданным. Таким образом, нет ничего непоследовательного или удивительного о комбинации полномочий S представляет (-x,+s). Это было бы так, даже если бы исполняемый файл, работающий как его владелец, потому что его владелец действительно выполнил его, работал точно то же исполняемым файлом, работающим как его владелец, потому что кто-то выполнил его, но это был setuid. Но это не то, как это работает.

Ядро использует больше чем одно число для отслеживания пользовательские идентификационные данные рабочего процесса. Одним таким числом является UID, и другой - EUID. См. эту статью для деталей. setuid укусил, заставляет EUID (эффективный идентификатор пользователя) быть измененным, но UID (идентификатор реального пользователя) остается тем же. Одно использование этого это, чтобы позволить сигналам, которыми обменяются между процессами, которые совместно используют UID, но имеют другой EUIDs, но другой - то, что это позволяет программу, которая разработана, чтобы иметь ее setuid набор битов для проверки, кто выполнил его.

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

$ ls -l "$(command -v passwd)"
-rwsr-xr-x 1 root root 54256 May 16 19:37 /usr/bin/passwd

-rwsr-xr-x имеет r-x в конце, для других. Из-за x, даже пользователи, которые не являются корнем или в корневой группе, могут работать passwd. И это имеет rws около начала, для владельца. Из-за s, прогоны программы как корень, даже когда невладельцы выполняют его. Но когда Вы работаете passwd самостоятельно, это изменяет Ваш пароль, не корень.

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

Это - типичный вариант использования setuid исполняемого файла: создать интерфейс, который позволяет одному пользователю заставлять действия быть выполненными как другой ограниченным способом, который проверяется кодом setuid исполняемого файла. Таким образом, это только безопасно для установки бита setuid (или setgid укусил) на программе, которая разработана, чтобы иметь те полномочия.

Это - другая часть загадки для понимания почему полномочия S имеет значение не загадка: питание, которое укусил setuid, совещается, не достигает того же самого как фактического запущения программы как ее владелец, даже после того как программе позволили работать.

Проверка UID и EUID с копией id шоу, как setuid работает.

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

• Исполняемый файл будет копией id программа, которая, среди прочего, сообщает о ее реальных и эффективных идентификаторах пользователей. Хотя эта программа не разработана, чтобы быть setuid, она также не разработана для изменения чего-либо вообще - кроме путем создания вывода - таким образом, это довольно безопасно. Но необходимо все еще удалить его впоследствии. (Ваша копия. Не оригинал.)
• Мы используем копию, не изменяя полномочия на оригинале. Вы не должны использовать sudo или выполните любое действие, как поддерживают это.
• Для выполнения его как другому пользователю Вам нужна вторая учетная запись пользователя, но можно использовать su выполнить действия как того пользователя. (По умолчанию, root учетная запись не позволяет Вам входить в систему как он с паролем, поэтому если Вы делаете ошибку и работаете su не давая имя пользователя Вы хотите переключиться на, Вы не закончите тем случайно, что стали корнем вместо этого, если Вы также не включили корневые логины. Если Вы действительно хотите использовать sudo -u user вместо su user -c, Тем не менее, затем Вы можете.)

Мою учетную запись основного пользователя называют ek и моя вторая учетная запись ek2. Это прекрасно, если Ваш отличаются. Во-первых, как ek, Я копирую id к текущему каталогу (который является где-нибудь в моем корневом каталоге):

$ type -a id
id is /usr/bin/id
$ cp /usr/bin/id .

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

$ ls -l id /usr/bin/id
-rwxr-xr-x 1 ek   ek   39760 Oct  5 11:23 id
-rwxr-xr-x 1 root root 39760 Mar  2  2017 /usr/bin/id

Передача -n кому: id шоу называют вместо Идентификационных номеров, -u показывает пользователю (и не другая информация как группы), и -r заставляет идентификатор реального пользователя быть показанным. Без -r, -u показывает эффективный идентификатор пользователя. Это поведение применяется полностью к копии id Я только что сделал.

Когда я выполняю его как пользователь замены, реальные и эффективные идентификаторы пользователей оба изменяются. Это - часть как su и sudo записаны, и не простой результат su самостоятельно будучи setuid корнем, хотя это. (Поэтому я использовал passwd как пример типичного setuid исполняемого файла, а не su или sudo.) Это - наша базовая линия, для наблюдения этого id в текущем каталоге работает как ожидалось:

$ ./id -nu                # ek runs id, displaying the effective user
ek
$ ./id -nur               # ek runs id, displaying the real user
ek
$ su ek2 -c './id -nu'    # ek2 runs id, displaying the effective user
Password:
ek2
$ su ek2 -c './id -nur'   # ek2 runs id, displaying the real user
Password:
ek2

Теперь я делаю эту локальную копию id setuid:

$ chmod u+s id
$ ls -l id
-rwsr-xr-x 1 ek ek 39760 Oct  5 11:42 id

Теперь, когда я выполняю его, его идентификатор реального пользователя является все еще идентификатором пользователя, который выполнил его, в то время как его эффективный идентификатор пользователя является идентификатором пользователя ek даже когда ek2 выполнения это:

$ ./id -nu                # ek runs id, displaying the effective user
ek
$ ./id -nur               # ek runs id, displaying the real user
ek
$ su ek2 -c './id -nu'    # ek2 runs id, displaying the effective user
Password:
ek
$ su ek2 -c './id -nur'   # ek2 runs id, displaying the real user
Password:
ek2

Теперь я убираю исполняемые полномочия от владельца, но оставляю их для всех остальных:

$ chmod u-x id
$ ls -l id
-rwSr-xr-x 1 ek ek 39760 Oct  5 11:42 id

ek2 может все еще выполнить его как с ekэффективный идентификатор пользователя, даже при том, что ek не может выполнить его:

$ ./id -nu                # ek runs id, displaying the effective user
-bash: ./id: Permission denied
$ ./id -nur               # ek runs id, displaying the real user
-bash: ./id: Permission denied
$ su ek2 -c './id -nu'    # ek2 runs id, displaying the effective user
Password:
ek
$ su ek2 -c './id -nur'   # ek2 runs id, displaying the real user
Password:
ek2

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

(Впоследствии, я работал rm id удалить файл, таким образом, у меня не было бы ненужного setuid исполняемого файла, лежащего вокруг в моем корневом каталоге. Или Вы могли просто сбросить бит setuid с chmod -s id.)