Používá se k něčemu spustitelný režim oprávnění S?

Pokud přidáte bit setuid pro oprávnění souboru tam, kde máte oprávnění ke spuštění, změní se x na s to znamená, že pokud tento soubor spustíte, bude se spouštět jako vlastník souboru, nikoli jako osoba, která jej skutečně spouští.

Ale také jsem si všiml, že pokud přidáte s oprávnění, ale odeberte x povolení se změní na S v seznamu oprávnění. Nějak by to znamenalo, že by to nemohlo být exekuováno, ale zároveň by to bylo exekuováno jako vlastník, kdyby to bylo možné provést? Je to tak?

Chápu toto povolení špatně? K čemu se používá? Co to znamená?

Přijatá odpověď:

Všechny čtyři kombinace existují a mají smysl.

„Může jej skutečný vlastník tohoto souboru spustit?“ a „Kdo bude systém předstírat, že spouští tento soubor?“ jsou dvě samostatné otázky. Všechny čtyři kombinace jsou možné a smysluplné.

Řetězce oprávnění zobrazené pomocí ls -l nebo stat -c %A show, na pozici spuštění vlastníka (tj. místo ? v ---?------ ), čtyři různé znaky, jeden pro každou kombinaci:

1. - znamená, že vlastník nemůže spusťte soubor, a pokud jej spustí uživatel, který není vlastníkem, spustí se jako tento jiný uživatel .
2. x znamená, že vlastník může spusťte soubor, a pokud jej spustí uživatel, který není vlastníkem, spustí se jako tento jiný uživatel .
3. S znamená, že vlastník nemůže spusťte soubor, a pokud jej spustí uživatel, který není vlastníkem, spustí se místo toho jako vlastník .
4. s znamená, že vlastník může spusťte soubor, a pokud jej spustí uživatel, který není vlastníkem, spustí se místo toho jako vlastník .

Setuid bit a prováděcí bity jsou samostatné bity a režim řetězec je opravdu jen pohodlný způsob zobrazení bitů oprávnění, včetně těch. Další způsob, jak o tom přemýšlet, je:

• x nebo s znamená, že je nastaven spouštěcí bit. - nebo S znamená, že není.
• s nebo S znamená, že je nastaven bit setuid. - nebo x znamená, že není.

Podobně skupina může nebo nemusí mít oprávnění ke spouštění souboru, a pokud je spuštěna, může nebo nemusí být spuštěna s jinou identitou skupiny, než má uživatel, který ji spouští. Chcete-li, aby soubor běžel s identitou skupiny vlastníka skupiny, nikoli uživatele, který jej spouští, nastavte bit setgid (------s--- nebo ------S--- ).

S nepředstavuje bit samostatného režimu. Je to jednoduše způsob, jak označit, že bit setuid (nebo setgid) je nastaven, ale odpovídající spustitelný bit není nastaven.

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

Můžete zkoumat samotné bity.

Chcete-li vidět, že se jedná o samostatné bity, použijte %a specifikátor formátu pro stat místo %A . Pro zjednodušení jsem zrušil nastavení všech ostatních bitů režimu.

$ 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

To je jasné… pokud vám vyhovuje osmička. Pokud to chcete vidět v binárním formátu (jsou bitů nakonec) můžete převést reprezentace:

$ 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 nastavuje efektivní ID uživatele, nikoli ID skutečného uživatele.

Spouštěcí bity řídí, zda může být pokus o spuštění souboru úspěšný či nikoli, zatímco bity setuid/setgid řídí, pod jehož identitou nový proces běží, pokud je povoleno jeho vytvoření. Na kombinaci oprávnění S tedy není nic nekonzistentního nebo překvapivého představuje (-x,+s ). Bylo by tomu tak, i kdyby spustitelný soubor spuštěný jako jeho vlastník, protože jeho vlastník skutečně běžel, fungoval úplně stejně jako spustitelný soubor spuštěný jako jeho vlastník, protože jej někdo spustil, ale byl nastaven. Ale takhle to nefunguje.

Jádro používá více než jedno číslo ke sledování identity uživatele běžícího procesu. Jedno takové číslo je UID a druhé je EUID. Podrobnosti naleznete v tomto článku. Setuid bit způsobí změnu EUID (efektivní uživatelské ID), ale UID (skutečné uživatelské ID) zůstává stejné. Jedním z jeho použití je umožnit výměnu signálů mezi procesy, které sdílejí UID, ale mají různé EUID, ale další je, že umožňuje programu, který je navržen tak, aby měl nastavený bit setuid tak, aby zkontroloval, kdo jej spustil .

Například passwd musí být setuid, protože pouze root může měnit položky v databázi hesel:

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

-rwsr-xr-x má r-x na konci pro ostatní . Kvůli x , mohou spustit passwd i uživatelé, kteří nejsou root nebo nejsou v kořenové skupině . A má rws blízko začátku, pro vlastníka . Kvůli s , program běží jako root, i když jej spouštějí uživatelé, kteří nejsou vlastníky. Ale když spustíte passwd vy, resetuje vaše heslo, nikoli rootovo.

passwd je schopný provádění jakýchkoli změn v databázi uživatelů a hesel, protože běží s efektivním uživatelským ID uživatele root. Je však navržen tak, aby odmítal změnit heslo kohokoli kromě uživatele, který jej spustil – kromě případů, kdy je tento uživatel root – protože kontroluje jeho skutečné uživatelské ID.

Související:gdomap a k čemu se používá?

Toto je typický případ použití spustitelného souboru setuid:vytvořit rozhraní, které jednomu uživateli umožňuje provádět akce jako jinému, omezeným způsobem, který je kontrolován kódem spustitelného souboru setuid. Je tedy bezpečné nastavit bit setuid (nebo bit setgid) pouze u programu, který je navržen mít tato oprávnění.

Toto je další díl skládačky, abyste pochopili, proč oprávnění S znamená, že nejsou žádná záhada:síla, kterou bit setuid poskytuje, není dosáhnout toho samého, jako ve skutečnosti spustit program jako jeho vlastník , i když bylo programu povoleno spuštění.

Kontrola UID a EUID pomocí kopie id ukazuje, jak funguje setuid.

Dobře, nastavím bit setuid na spustitelný soubor, který pro něj není určen, abych ukázal, jak jsou ovlivněna skutečná a efektivní ID uživatelů.

• Spustitelný soubor bude kopií z id program, který mimo jiné hlásí svá skutečná a efektivní uživatelská ID. I když tento program není navržen jako setuid, není také navržen tak, aby vůbec něco měnil – kromě vytváření výstupu – takže je to přiměřeně bezpečné. Ale stejně byste to měli poté smazat. (Vaše kopie. Ne originál.)
• Používáme kopii, ne změna oprávnění na originálu. Vy ne musíte použít sudo nebo pro to proveďte jakoukoli akci jako root.
• Chcete-li jej spustit jako jiný uživatel, potřebujete druhý uživatelský účet, ale můžete použít su provádět akce jako takové uživatel. (Ve výchozím nastavení root účet vám neumožňuje přihlásit se pomocí hesla, takže pokud uděláte chybu a spustíte su bez zadání uživatelského jména, na které se chcete přepnout, se místo toho nestanete omylem rootem, pokud jste také nepovolili přihlášení root. Pokud opravdu chcete použít sudo -u user místo su user -c , ale pak můžete.)

Můj hlavní uživatelský účet se jmenuje ek a můj druhý účet je ek2 . Je v pořádku, když jsou ty vaše jiné. Nejprve jako ek , zkopíruji id do aktuálního adresáře (který je někde uvnitř mého domovského adresáře):

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

Kopie má vlastnictví uživatele bez oprávnění root, který ji zkopíroval, ale původní oprávnění:

$ 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

Předání -n na id zobrazuje jména místo ID čísel, -u zobrazuje uživatele (a ne další informace jako skupiny) a -r způsobí zobrazení skutečného ID uživatele. Bez -r , -u zobrazuje skutečné ID uživatele. Toto chování se plně vztahuje na kopii z id Právě jsem udělal.

Když jej spustím jako náhradní uživatel, změní se obě skutečná a efektivní ID uživatele. Toto je část jak su a sudo jsou zapsány a nejsou pouhým výsledkem su sám je setuid root, i když je. (Proto jsem použil passwd jako příklad typického spustitelného souboru setuid, spíše než su nebo sudo .) Toto je naše základní linie, abychom viděli to id v aktuálním adresáři funguje podle očekávání:

$ ./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

Nyní vytvořím tuto místní kopii id setuid:

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

Nyní, když jej spustím, jeho skutečné uživatelské ID je stále ID uživatele, který jej spustil, zatímco jeho skutečné uživatelské ID je ID ek i když ek2 spustí:

$ ./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

Nyní odeberu spustitelná oprávnění vlastníkovi, ale ponechám je všem ostatním:

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

ek2 stále jej lze spustit jako ek je efektivní ID uživatele, i když ek nejde to spustit:

$ ./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

Ale jak je ukázáno, toto nepřineslo stejný výsledek jako ek vlastně to provozuje. ek2 opravdu neumí to, co ek mohl udělat if ek bylo povoleno program spustit, pokud to program nepovoluje.

Související:Nelze spustit Ubuntu na Acer Aspire ES17?

(Potom jsem spustil rm id odstranit soubor, takže bych v domovském adresáři neměl zbytečný spustitelný soubor setuid. Nebo můžete jednoduše zrušit nastavení bitu setuid pomocí chmod -s id .)