- Nøyaktig diagnose av tilgangsfeil ved å verifisere POSIX-lag, ACL-er og sikkerhetsmoduler som SELinux.
- Riktig bruk av verktøy for tillatelsesadministrasjon som chmod, chown og visudo-verktøyet for å unngå sårbarheter.
- Systemgjenopprettingsmetoder ved bruk av Live CD eller oppstartsskript når superbrukertilgang er mistet.
Jeg er sikker på at det har skjedd deg: du prøver å kjøre en kommando, åpne en fil eller få tilgang til en mappe, og terminalen viser den beryktede meldingen «Nei tilgang» . Det er et frustrerende øyeblikk, spesielt når du tror du har full kontroll over systemet, men Linux er veldig strenge når det gjelder sikkerhet og slipper deg ikke gjennom med mindre du følger reglene strengt.
Fristelsen til å gi slipp chmod 777 Det er en stor midlertidig løsning, men ærlig talt, det er den verst tenkelige ideenÅ gjøre det er som å la inngangsdøren stå på vidt gap midt i byen; det løser tilgangsproblemet, men etterlater systemet fullstendig eksponert for enhver sårbarhet. Ideelt sett bør du forstå hva som feiler og bruke den riktige løsningen.
Forstå tillatelsessystemet i Linux
For å unngå å gå i blinde, er det viktig å vite at Linux administrerer tilgang på tre forskjellige nivåer. Først er det de klassiske POSIX-tillatelsene , som er den typiske trioen av lese (r), skrive (w) og utførelse (x) for eieren, gruppen og alle andre. Så er det utvidede ACL-er, som tillater mye finere regler for spesifikke brukere, og til slutt obligatoriske sikkerhetsmoduler som SELinux i RHEL eller AppArmor i Ubuntu og Debian.
Når vi snakker om kataloger, er det én detalj som ofte forvirrer mange: utførelsesbiten. I en mappe betyr ikke utførelsestillatelse at du kan starte et program; den lar deg bare navigere i katalogen . Hvis denne biten ikke er angitt, vil du ikke kunne få tilgang til en intern fil, selv om du har lesetillatelse for den fordi banen er låst.
Tillatelseshåndtering kan gjøres på to måter. Symbolske metoder er veldig praktiske for raske endringer, for eksempel å legge til utførelse med chmod u+x. På den annen side, oktal form Det er den mest presise måten å konfigurere alt på én gang. For eksempel er 644 standarden for tekstfiler, mens 755 er typisk for kataloger og offentlige skript der Alle kan bla gjennom men bare eieren skriver.
Vanlige blokkeringsscenarier og hvordan man håndterer dem
En av de vanligste feilene oppstår med SSH-nøkler. Hvis tillatelsene dine for den private nøkkelen er for permissive, vil serveren avvise tilkoblingen din på grunn av parameteren. StrictModesLøsningen her er å begrense tilgangen så mye som mulig, vanligvis ved å bruke chmod 600 slik at bare eieren kan lese nøkkelen.
Et annet vanlig scenario er når du prøver å skrive til systemstier som /etc o /var/wwwHvis det er en engangshendelse, bruk sudo Det stemmer. Men hvis det er et program som må skrive konstant, er den reneste tilnærmingen å endre mappens eierskap med chown slik at tjenestebrukeren er den juridiske eieren, og dermed unngår man Feil bruk av root-brukeren i Linux.
Noen ganger, selv som root, vil du få beskjed om at du ikke har tillatelse. Dette skjer vanligvis hvis filsystemet er montert i skrivebeskyttet modus (ro) eller hvis filen har attributtet immutable. For sistnevnte kan du bruke kommandoen lsattr å diagnostisere det og sudo chattr -i å fjerne den spesielle beskyttelsen.
Hodepinen av feil i svette
Sudo er et fantastisk verktøy helt til du ikke lenger kan bruke det. Filen /etc/sudoers Det er ekstremt delikat. En enkel syntaksfeil, som for eksempel et feilplassert komma eller et mellomrom på feil sted, kan forårsake sudo sluttet å virke fullstendig, og utelukker deg fra din egen administrasjon.
For å unngå dette, bør du aldri redigere denne filen med et vanlig tekstredigeringsprogram. visudo Det er nøkkelen, fordi validerer syntaksen Før du lagrer endringene. Hvis du prøver å tvinge frem redigeringen og ødelegge filen, vil du havne i en blindvei: du trenger sudo for å fikse filen, men du kan ikke bruke sudo fordi filen er ødelagt.
I tillegg til syntaksfeil finnes det eierskapsfeil. Sudo nekter å fungere hvis filen /etc/sudoers har altfor åpne tillatelser (som å være skrivbar av alle) eller hvis eieren er ikke rootI slike tilfeller vil systemet gi en advarsel som indikerer at filen er verden skrivbar eller at UID-en er feil.
Slik gjenoppretter du tilgangen når alt annet mislykkes
Hvis du har blitt for lur og ødelagt sudoers-filen, er ikke alt tapt. En av de mest effektive måtene er å starte systemet med en Ubuntu Live CDDerfra monterer du harddisken din og navigerer til katalogen. /etc fra den faktiske installasjonen din og korriger tillatelsene manuelt med chmod 440 y chown root:root.
I skymiljøer som Google Cloud finnes det et alternativ ved å bruke oppstartsskript . Du kan konfigurere metadata som utfører en kommando når den virtuelle maskinen starter. Denne kommandoen kan gi nytt navn til den ødelagte sudoers-filen og opprette en ny, enkel fil som lar deg logge inn midlertidig uten passord, slik at du kan reparere skaden med Visudo.
Hvis problemet er at du har filer .lock blokkering av redigering av brukere eller grupper i /etc/passwdDu må kanskje rydde opp i disse midlertidige filene fra et gjenopprettingsmiljø, slik at systemet lar deg gjøre administrative endringer igjen.
For å løse ethvert tilgangsproblem er det smarteste å følge en logisk rekkefølge: start med å bruke ls -l e id for å se hvem som er hvem, juster delene med chmod, korriger egenskapen med chown Og hvis ingenting av dette fungerer, sjekk dypere lag som SELinux eller AppArmor som kan blokkere handlingen i bakgrunnen, og utnytte det faktum at du allerede vet Linux-hemmeligheter og kommandoene deres.
Lidenskapelig forfatter om verden av bytes og teknologi generelt. Jeg elsker å dele kunnskapen min gjennom å skrive, og det er det jeg skal gjøre i denne bloggen, vise deg alle de mest interessante tingene om dingser, programvare, maskinvare, teknologiske trender og mer. Målet mitt er å hjelpe deg med å navigere i den digitale verden på en enkel og underholdende måte.