Hvordan fungerer den klissete biten?

SUID

den klissete biten som brukes på kjørbare programmer som flagger systemet for å beholde et bilde av programmet i minnet etter at programmet ble kjørt.

Men jeg vet ikke hva det er lagret i minnet. Og hvordan kan jeg se dem, i dette tilfellet.?

Kommentarer

Svar

Dette er trolig en av de mest irriterende tingene mine folk roter til hele tiden. SUID / GUID-biten og sticky-biten er to helt forskjellige ting.

Hvis du gjør en man chmod kan du lese om SUID og sticky-bits. man-siden er også tilgjengelig her .

bakgrunn

utdrag

Bokstavene rwxXst velger filmodusbiter for berørte brukere: les (r), skriv (w), kjør (eller søk etter kataloger) (x), kjør / søk bare hvis filen er en katalog eller allerede har utføringstillatelse for noen brukere (X), angi bruker- eller gruppe-ID ved kjøring (er) , begrenset slettingsflagg eller klebrig bit ( t) .

SUID / GUID

Hva ovenstående manside er prøver å si er at posisjonen som x-biten tar i rwxrwxrwx for brukerens oktale (1. gruppe av rwx) og gruppen oktal (2. gruppe av rwx) kan ta en ekstra tilstand der x blir en s. Når dette skjer, kjøres denne filen når den kjøres (hvis den er et program og ikke bare et skallskript) med tillatelse fra eieren eller gruppen av filen.

Så hvis filen eies av root og SUID-biten er slått på, vil programmet kjøre som root. Selv om du utfører det som en vanlig bruker. Det samme gjelder GUID-biten.

utdrag

SETUID OG SETGID BITS

chmod tømmer set-group-ID-biten til en vanlig fil hvis filens gruppe-ID gjør samsvarer ikke med brukerens effektive gruppe-ID eller en av brukerens supplerende gruppe-ID-er, med mindre brukeren har passende rettigheter. Ytterligere begrensninger kan føre til at set-user-ID og set-group-ID bits av MODE eller RFILE ignoreres. Denne oppførselen avhenger av policyen og funksjonaliteten til den underliggende chmod-systemanropet. Hvis du er i tvil, sjekk den underliggende systematferden.

chmod bevarer katalogens set-user-ID og set-group-ID bits med mindre du eksplisitt angir noe annet. Du kan angi eller fjerne bitene med symbolsk moduser som u + s og gs, og du kan angi (men ikke fjerne) bitene med en numerisk modus.

SUID / GUID eksempler

ingen suid / guid – bare bitene rwxr-xr-x er satt .

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

suid & brukerens kjørbare bit aktivert (små bokstaver) – bitene rwsr-xrx er angitt.

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

suid aktivert & kjørbar bit deaktivert (store bokstaver S) – bitene rwSr-xr-x er angitt.

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

guid & gruppe «kjørbar bit aktivert (små bokstaver) – bitene rwxr-sr-x er angitt.

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

guid aktivert & kjørbar bit deaktivert (store bokstaver S) – bitene rwxr-Sr-x er satt.

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

klissbit

Den klissete biten på annen hånd er betegnet som t, slik som med /tmp katalogen:

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

Denne biten burde alltid vært kalt «begrenset slettingsbit», gitt at det er hva den egentlig betyr. Når denne modusbiten er aktivert, lager den en katalog slik at brukere bare kan slette filer & kataloger i den som de er eiere av.

utdrag

BEGRENSET SLETTINGSFLAGG ELLER STICKY BIT

Det begrensede slettingsflagget eller klebrig biten er en enkelt bit, hvis tolkning avhenger av filtypen. For kataloger forhindrer det ikke privilegerte brukere fra å fjerne eller gi nytt navn til en fil i katalogen med mindre de eier filen eller katalogen. Dette kalles det begrensede slettingsflagget for katalogen, og finnes ofte i kataloger som / tmp.For vanlige filer på noen eldre systemer lagrer biten programmets tekstbilde på bytteenheten slik at den lastes raskere når den kjøres. Dette kalles den klebrig biten.

Kommentarer

  • Faktisk kunne sticky-biten tidligere brukes på kjørbare filer, noe som førte til at disse ble værende i bytte etter at de først ble lastet inn. Dette kan spare mye unødvendig disk / nettverk (NFS) og CPU-bruk for programmer som ble mye brukt. Imidlertid støtter verken Linux eller de fleste (alle?) Unix-systemene dette lenger (det ble fjernet fra kjernen). Det ' s " klebrig ", fordi den kjørbare filen satt fast i bytte. I tillegg ble den brukt til kataloger som du beskriver.
  • Egentlig ville " mye brukt eller veldig stor " være en bedre beskrivelse. Husk at college hadde nettleseren Netscape som " klebrig " på deres HP-UX-datamaskin tilbake i 1995. Så små programmer som ofte ble brukt (f.eks. systemkommandoer kjørte ofte av cron) og store programmer (f.eks. Netscape) var hovedkandidater som skulle gjøres " klebrig ". I begge tilfeller ville det være bortkastet å laste dem kontinuerlig fra disk / NFS.
  • Sticky-bit-programmer var ment å forbli bosatt i RAM, ikke i bytte (å laste inn et bilde fra en byttefil er ikke ' t det mye raskere enn å laste det fra en filsystemdisk). Det var ment for viktige OS-nivå kommandoer som ls. Åpenbart var det bare superbrukeren som kunne sette den klissete biten på en fil. Det ble mindre viktig etter at virtuelt minne og delte biblioteker ble introdusert, og spesielt ettersom personsøkere ble smartere og dynamisk kan bestemme hvilke sider som skal være bosatt.
  • Og siden den klebrig egenskapen ikke ga mening for en katalog, var det samme bit av tillatelsesmasken ble senere tolket for å modifisere den tradisjonelle semantikken for filoppretting for kataloger.
  • @alexis: Opprinnelig ble klissete bitprogrammer holdt i bytteområdet. Dette var mye raskere enn å lese fra filsystemet fordi lesing av byttefilbilder var sammenhengende sektorer og så kunne leses stort sett asynkront. Med de tidlige filsystemene var det ingen sektor " kjørelengder ", og de fleste tidlige filsystemdriverne leste en sektor om gangen selv om sektorene tilfeldigvis var sammenhengende. Resultatet på en PDP-40 var at klissete programmer så ut til å lastes øyeblikkelig mens ikke-klissete programmer tok det vanlige sekundet eller to. Jeg tror vi bare hadde ed klissete.

Svar

«Den klissete biten som brukes på kjørbare programmer som flagger systemet for å holde et bilde av programmet i minnet etter at programmet er kjørt.»

Jeg tror at «det er ganske foreldet info, i dag ignorerer de fleste moderne Unixes det. I Linux er den klebrig biten bare relevant for kataloger. Se her og den ganske informative Wikipedia-artikkelen .

Uansett, i den gamle oppførselen bildet (bare «koden», ikke dataene) ble bare oppbevart i virtuelt minne -byttet normalt, ikke i ekte minne, for å kjøre det raskere neste gang.

Svar

Hva er klebrig biter?

En klissbit er en tillatelsesbit som er satt i en katalog som bare tillater eieren av filen i t hatkatalogen eller rotbrukeren for å slette eller gi nytt navn til filen. Ingen andre brukere har de nødvendige rettighetene til å slette filen som er opprettet av en annen bruker.

Dette er et sikkerhetstiltak for å unngå sletting av kritiske mapper og innholdet (underkataloger og filer), selv om andre brukere har full tillatelse.

Kommentarer

  • At ' ikke stemmer: no.wikipedia.org/wiki/Sticky_bit
  • @AB Det virker ganske nøyaktig for meg, nesten til å omskrive begynnelsen på Wikpedia-artikkelen du siterer. Hva ' er galt med det?
  • Jeg vil si at svaret er ufullstendig. " Sticky " angir også at den kjørbare filen vil bli holdt i bytteområdet for å få den til å gå raskere. Dette er eldgamle historier, men i eldre filsystemer pleide drivere å lese en sektor om gangen, selv om sektorene tilfeldigvis var sammenhengende. Dette gjorde at ikke-klebrig kjørbare filer var treg, klebrighet ga mye mening på den tiden.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *