Hur fungerar den klibbiga biten?

Det här är förmodligen en av mina mest obehagliga saker som människor trasslar hela tiden. SUID / GUID-biten och sticky-biten är två helt olika saker.

Om du gör en man chmod kan du läsa om SUID och sticky-bits. man-sidan finns också här .

bakgrund

utdrag

Bokstäverna rwxXst väljer fillägesbitar för drabbade användare: läs (r), skriv (w), kör (eller sök efter kataloger) (x), kör / sök bara om filen är en katalog eller redan har exekveringsbehörighet för någon användare (X), ställer in användar- eller grupp-ID vid körning (er) , begränsad raderingsflagga eller sticky bit ( t) .

SUID / GUID

Vad ovanstående mansida är försöker säga är att positionen som x-biten tar i rwxrwxrwx för användarens oktala (första gruppen av rwx) och gruppen oktal (andra gruppen av rwx) kan ta ett ytterligare tillstånd där x blir ett s. När detta inträffar körs den här filen när den körs (om det är ett program och inte bara ett skalskript) med behörighet för ägaren eller gruppens fil.

Så om filen ägs av root och SUID-biten är påslagen kommer programmet att köras som root. Även om du kör det som en vanlig användare. Samma sak gäller GUID-biten.

utdrag

SETUID OCH SETGID BITS

chmod rensar set-group-ID-biten för en vanlig fil om filens grupp-ID gör matchar inte användarens effektiva grupp-ID eller ett av användarens kompletterande grupp-ID, såvida inte användaren har lämpliga behörigheter. Ytterligare begränsningar kan göra att set-user-ID och set-group-ID-bitarna i MODE eller RFILE ignoreras. Detta beteende beror på policyn och funktionaliteten för det underliggande chmod-systemanropet. Om du är osäker, kontrollera det underliggande systembeteendet.

chmod bevarar en katalogs set-user-ID och set-group-ID bits om du inte uttryckligen anger något annat. Du kan ställa in eller rensa bitarna med symbolisk lägen som u + s och gs, och du kan ställa in (men inte rensa) bitarna med ett numeriskt läge.

SUID / GUID-exempel

inget suid / guid – bara bitarna rwxr-xr-x är inställda .

$ ls -lt b.pl -rwxr-xr-x 1 root root 179 Jan 9 01:01 b.pl 

suid & användares körbara bit aktiverat (små bokstäver) – bitarna rwsr-xrx är inställda.

$ chmod u+s b.pl $ ls -lt b.pl -rwsr-xr-x 1 root root 179 Jan 9 01:01 b.pl 

suid aktiverat & körbar bit inaktiverad (versal S) – bitarna rwSr-xr-x är inställda.

$ chmod u-x b.pl $ ls -lt b.pl -rwSr-xr-x 1 root root 179 Jan 9 01:01 b.pl 

guid & gruppens körbara bit aktiverat (små bokstäver) – bitarna rwxr-sr-x är inställda.

$ chmod g+s b.pl $ ls -lt b.pl -rwxr-sr-x 1 root root 179 Jan 9 01:01 b.pl 

guid aktiverad & körbar bit inaktiverad (versal S) – bitarna rwxr-Sr-x är inställda.

$ chmod g-x b.pl $ ls -lt b.pl -rwxr-Sr-x 1 root root 179 Jan 9 01:01 b.pl 

klibbig bit

Den klibbiga biten på andra handen betecknas som t, som med /tmp -katalogen:

$ ls -l /|grep tmp drwxrwxrwt. 168 root root 28672 Jun 14 08:36 tmp 

Den här biten borde alltid ha kallats ”begränsad borttagningsbit” med tanke på att det är vad den verkligen betyder. När denna lägesbit är aktiverad skapar den en katalog så att användare bara kan ta bort filer & kataloger i den som de är ägare till.

utdrag

BEGRÄNSAD RADERINGSFLAGG ELLER STICKY BIT

Den begränsade raderingsflaggan eller klibbiga biten är en enda bit vars tolkningen beror på filtypen. För kataloger förhindrar det
privilegierade användare att ta bort eller byta namn på en fil i katalogen såvida de inte äger filen eller katalogen. detta kallas den begränsade borttagningsflaggan för katalogen och finns vanligtvis i världsskrivbara kataloger som / tmp.För vanliga filer på vissa äldre system sparar biten programmets textbild på swap-enheten så att den laddas snabbare när den körs. Detta kallas sticky bit.

Kommentarer

• Egentligen kunde sticky-biten tidigare tillämpas på körbara filer, vilket fick dem att förbli i swap efter att de först laddades. Detta kan spara massor av onödig disk / nätverk (NFS) och CPU-användning för program som användes mycket. Men varken Linux eller de flesta (alla?) Unix-system stöder detta längre (det togs bort från kärnan). Det ' s " klibbig ", eftersom den körbara filen fastnade i swap. Dessutom användes den för kataloger som du beskriver.
• Egentligen " mycket använda eller mycket stora " skulle vara en bättre beskrivning. Kom ihåg att mitt college hade webbläsaren Netscape som " klibbig " på sin HP-UX-dator 1995. Så små program som ofta användes (t.ex. systemkommandon kördes ofta av cron) och stora program (t.ex. Netscape) var de främsta kandidaterna för att göra " klibbig ". I båda fallen skulle det vara slösande att ständigt ladda om dem från disk / NFS.
• Sticky-bit-program var tänkta att vara kvar i RAM, inte i swap (att ladda en bild från en swap-fil är inte ' t så mycket snabbare än att ladda den från en filsystemdisk). Det var avsett för viktiga OS-nivå-kommandon som ls. Uppenbarligen kunde bara superanvändaren ställa in den klibbiga biten på en fil. Det blev mindre viktigt efter att virtuellt minne och delade bibliotek introducerades, och särskilt eftersom personsökare blev smartare och dynamiskt kan bestämma vilka sidor som ska behållas.
• Och eftersom den klibbiga egenskapen inte gav någon mening för en katalog, samma bit av behörighetsmasken senare tolkades för att modifiera den traditionella filskapande semantiken för kataloger.
• @alexis: Ursprungligen hölls klibbiga bitprogram i bytesutrymme. Detta var mycket snabbare än att läsa från filsystemet eftersom läsning av swap-filbilder var sammanhängande sektorer och sålunda kunde läsas mestadels asynkront. Med de tidiga filsystemen fanns ingen sektor " körlängder " och de flesta tidiga filsystemdrivrutiner läser en sektor i taget även om sektorerna råkade vara i följd. Resultatet på en PDP-40 var att klibbiga program tycktes laddas omedelbart medan icke-klibbiga program tog den vanliga sekunden eller två. Jag tror att vi bara hade ed klibbiga.