Tillatelser i Linux (chown, chmod, SUID, GUID, sticky bit, ACL, umask)

Hei alle sammen. Dette er en oversettelse av en artikkel fra boken RedHat RHCSA RHCE 7 RedHat Enterprise Linux 7 EX200 og EX300.

Trykk: Jeg håper artikkelen vil være nyttig ikke bare for nybegynnere, men vil også hjelpe mer erfarne administratorer å strømlinjeforme kunnskapen sin.

Så la oss gå.

For å få tilgang til filer i Linux, brukes tillatelser. Disse tillatelsene er tildelt tre objekter: fileieren, gruppeeieren og et annet objekt (det vil si alle andre). I denne artikkelen lærer du hvordan du bruker tillatelser.

Denne artikkelen begynner med en oversikt over de grunnleggende konseptene, etterfulgt av en diskusjon av spesielle tillatelser og tilgangskontrolllister (ACL). På slutten av denne artikkelen dekker vi innstilling av standardtillatelser via umask, samt administrering av utvidede brukerattributter.

Fileierskapsbehandling

Før du diskuterer tillatelser, bør du være klar over rollen som fil- og katalogeier. Eierskap til filer og kataloger er avgjørende for å håndtere tillatelser. I denne delen vil du først lære hvordan du kan se eieren. Du vil da lære hvordan du endrer gruppeeier og bruker for filer og kataloger.

Viser eieren av en fil eller katalog

I Linux har hver fil og hver katalog to eiere: en bruker og en gruppeeier.

Disse eierne angis når en fil eller katalog opprettes. Brukeren som oppretter filen blir eieren av den filen, og den primære gruppen som den samme brukeren tilhører, blir også eieren av filen. For å finne ut om du som bruker har tillatelse til å få tilgang til en fil eller katalog, sjekker skallet for eierskap.

Dette skjer i følgende rekkefølge:

1. Skallet sjekker om du er eieren av filen du vil ha tilgang til. Hvis du er eieren, får du tillatelser og skallet slutter å sjekke.
2. Hvis du ikke er eieren av filen, vil skallet sjekke om du er medlem av en gruppe som har tillatelser til filen. Hvis du er medlem av denne gruppen, vil du få tilgang til filen med tillatelsene som gruppen har angitt, og skallet vil slutte å sjekke.
3. Hvis du verken er bruker eller eier av en gruppe, gis du rettighetene til andre brukere (Annet).

For å se gjeldende eieroppdrag kan du bruke kommandoen ls-l. Denne kommandoen viser brukeren og eieren av gruppen. Nedenfor kan du se eierinnstillingene for kataloger i /home-katalogen.

[root@server1 home]# ls -l
total 8
drwx------. 3  bob            bob            74     Feb   6   10:13 bob
drwx------. 3  caroline       caroline       74     Feb   6   10:13 caroline
drwx------. 3  fozia          fozia          74     Feb   6   10:13 fozia
drwx------. 3  lara           lara           74     Feb   6   10:13 lara
drwx------. 5  lisa           lisa           4096   Feb   6   10:12 lisa
drwx------. 14 user           user           4096   Feb   5   10:35 user

Med kommandoen ls du kan vise eieren av filene i en gitt katalog. Noen ganger kan det være nyttig å få en liste over alle filer på systemet som har en gitt bruker eller gruppe som eier. For dette kan du bruke finne. Argument finn-bruker kan brukes til dette formålet. For eksempel viser følgende kommando alle filer som eies av brukeren linda:

find / -user linda

Du kan også bruke finne for å søke etter filer som har en bestemt gruppe som eier.

For eksempel søker følgende kommando etter alle filer som tilhører gruppen Brukere:

find / -group users

Eierskifte

For å bruke de riktige tillatelsene, er det første du må vurdere eierskap. Det er en kommando for dette chown. Syntaksen til denne kommandoen er lett å forstå:

chown кто что

For eksempel endrer følgende kommando eieren av /home/account-katalogen til brukeren linda:

chown linda /home/account

Lag chown har flere alternativer, hvorav ett er spesielt nyttig: -R. Du kan gjette hva det gjør fordi dette alternativet er tilgjengelig for mange andre kommandoer også. Dette lar deg angi eieren rekursivt, som lar deg angi eieren av gjeldende katalog og alt nedenfor. Følgende kommando endrer eierskap av /home-katalogen og alt under den til linda-brukeren:

Nå ser eierne slik ut:

[root@localhost ~]# ls -l /home
total 0
drwx------. 2 account account 62 Sep 25 21:41 account
drwx------. 2 lisa    lisa    62 Sep 25 21:42 lisa

La oss gjøre:

[root@localhost ~]# chown -R lisa /home/account
[root@localhost ~]#

Nå har brukeren lisa blitt eier av kontokatalogen:

[root@localhost ~]# ls -l /home
total 0
drwx------. 2 lisa account 62 Sep 25 21:41 account
drwx------. 2 lisa lisa    62 Sep 25 21:42 lisa

Endre eier av en gruppe

Det er to måter å endre eierskapet til en gruppe på. Du kan gjøre dette ved å bruke chown, men det er en spesiell kommando som heter chgrpsom gjør jobben. Hvis du vil bruke kommandoen chown, bruk . eller : foran gruppenavnet.

Følgende kommando endrer enhver eier av /home/kontogruppen til kontogruppen:

chown .account /home/account

du kan bruke chown å endre eier av en bruker og/eller gruppe på flere måter. Her er noen eksempler:

• chown lisa myfile1 setter brukeren lisa som eier av minfil1.
• chown lisa.sales myfile setter brukeren lisa som eier av myfile-filen, og setter også salgsgruppen som eier av samme fil.
• chown lisa:sales myfile det samme som forrige kommando.
• chown .sales myfile setter salgsgruppen som eier av myfile uten å endre eieren av brukeren.
• chown :sales myfile det samme som forrige kommando.

Du kan bruke kommandoen chgrpfor å endre eieren av gruppen. Tenk på følgende eksempel, hvor du kan bruke chgrp angi eieren av kontokatalogen til salgsgruppen:

chgrp .sales /home/account

Som med chown, kan du bruke alternativet -R с chgrp, samt rekursivt endre eieren av gruppen.

Forstå standardeieren

Du har kanskje lagt merke til at når en bruker oppretter en fil, brukes standard eierskap.
Brukeren som oppretter filen blir automatisk eieren av filen, og den brukerens primærgruppe blir automatisk eieren av filen. Dette er vanligvis gruppen som er oppført i filen /etc/passwd som brukerens primære gruppe. Men hvis brukeren er medlem av mer enn én gruppe, kan brukeren endre den effektive primærgruppen.

For å vise gjeldende effektive primærgruppe kan brukeren bruke kommandoen grupper:

[root@server1 ~]# groups lisa
lisa : lisa account sales

Hvis den nåværende linda-brukeren ønsker å endre den effektive primærgruppen, vil han bruke kommandoen nygrpetterfulgt av navnet på gruppen han vil angi som den nye effektive primærgruppen. Etter å ha brukt kommandoen nygrp primærgruppen vil være aktiv til brukeren skriver inn en kommando avslutte eller ikke logge ut.

Følgende viser hvordan brukeren linda bruker denne kommandoen, med salg som primærgruppe:

lisa@server1 ~]$ groups
lisa account sales
[lisa@server1 ~]$ newgrp sales
[lisa@server1 ~]$ groups
sales lisa account
[lisa@server1 ~]$ touch file1
[lisa@server1 ~]$ ls -l
total 0
-rw-r--r--. 1 lisa sales 0 Feb 6 10:06 file1

Etter å ha endret den effektive primærgruppen, vil alle nye filer opprettet av brukeren ha den gruppen som gruppeeier. For å gå tilbake til den opprinnelige primærgruppeinnstillingen, bruk avslutte.

For å kunne bruke kommandoen nygrp, må brukeren være medlem av gruppen de vil bruke som primærgruppe. I tillegg kan et gruppepassord brukes for en gruppe ved å bruke kommandoen gpasswd. Hvis brukeren bruker kommandoen nygrpmen ikke er medlem av målgruppen, ber skallet om gruppens passord. Etter at du har angitt riktig gruppepassord, vil en ny effektiv primærgruppe opprettes.

Forvaltning av grunnleggende rettigheter

Linux-tillatelsessystemet ble oppfunnet på 1970-tallet. Siden databehovet var begrenset i disse årene, var det grunnleggende tillatelsessystemet ganske begrenset. Dette tillatelsessystemet bruker tre tillatelser som kan brukes på filer og kataloger. I denne delen lærer du hvordan du bruker og endrer disse tillatelsene.

Forstå lese-, skrive- og utføringstillatelser

Tre grunnleggende tillatelser lar deg lese, skrive og kjøre filer. Effekten av disse tillatelsene varierer når de brukes på filer eller kataloger. For en fil gir lesetillatelsen deg rett til å åpne filen for lesing. Derfor kan du lese innholdet, men det betyr at datamaskinen din kan åpne filen for å gjøre noe med den.

En programfil som trenger tilgang til et bibliotek må for eksempel ha lesetilgang til det biblioteket. Det følger at lesetillatelsen er den mest grunnleggende tillatelsen du trenger for å jobbe med filer.

Når den brukes på en katalog, lar lesing deg vise innholdet i den katalogen. Du bør være klar over at denne tillatelsen ikke tillater deg å lese filene i katalogen. Linux-tillatelsessystemet kjenner ikke arv, og den eneste måten å lese en fil på er å bruke lesetillatelser på den filen.

Som du sikkert kan gjette, tillater skrivetillatelse, hvis den brukes på en fil, å skrive til filen. Med andre ord lar den deg endre innholdet i eksisterende filer. Den lar deg imidlertid ikke opprette eller slette nye filer eller endre filtillatelser. For å gjøre dette må du gi skrivetillatelse til katalogen der du vil opprette filen. I kataloger lar denne tillatelsen deg også opprette og slette nye underkataloger.

Kjøringstillatelse er det du trenger for å kjøre filen. Det vil aldri bli installert som standard, noe som gjør Linux nesten helt immun mot virus. Bare noen med skrivetillatelser på katalogen kan bruke utføringstillatelse.

Følgende oppsummerer bruken av grunnleggende tillatelser:

Bruker chmod

Kommandoen brukes til å administrere tillatelser. chmod... Ved hjelp av chmod du kan angi tillatelser for brukeren (brukeren), grupper (gruppe) og andre (annet). Du kan bruke denne kommandoen i to moduser: relativ modus og absolutt modus. I absolutt modus brukes tre sifre til å angi grunnleggende tillatelser.

Når du angir tillatelser, beregne verdien du trenger. Hvis du vil sette les/skriv/utfør for bruker, les/utfør for gruppe og les/utfør for andre i /somefile, bruker du følgende kommando chmod:

chmod 755 /somefile

Når du bruker chmod på denne måten erstattes alle gjeldende tillatelser av tillatelsene du angir.

Hvis du vil endre tillatelsene i forhold til gjeldende tillatelser, kan du bruke chmod i relativ modus. Ved hjelp av chmod i relativ modus jobber du med tre indikatorer for å indikere hva du vil gjøre:

1. Først spesifiserer du hvem du vil endre tillatelser for. For å gjøre dette kan du velge mellom bruker (u), gruppe (g) og andre (o).
2. Du bruker deretter en uttalelse for å legge til eller fjerne tillatelser fra gjeldende modus, eller angi dem absolutt.
3. På slutten bruker du r, w и xfor å angi hvilke tillatelser du vil angi.

Når du endrer tillatelser i relativ modus, kan du hoppe over "til"-delen for å legge til eller fjerne tillatelser for alle objekter. For eksempel legger denne kommandoen til utførelsestillatelse for alle brukere:

chmod +x somefile

Når du arbeider i relativ modus, kan du også bruke mer komplekse kommandoer. For eksempel legger denne kommandoen til skrivetillatelse til en gruppe og fjerner lesetillatelse for andre:

chmod g+w,o-r somefile

Ved bruk chmod -R o+rx /data du setter utføringstillatelse for alle kataloger så vel som filer i /data-katalogen. For å angi utførelsestillatelse kun for kataloger og ikke for filer, bruk chmod -R o+ rX /data.

Den store X-en sikrer at filer ikke får utføringstillatelse med mindre filen allerede har satt utføringstillatelse for enkelte objekter. Dette gjør X til en smartere måte å håndtere utførelsestillatelser på; dette vil unngå å sette denne tillatelsen på filer der det ikke er nødvendig.

Utvidede rettigheter

I tillegg til de grunnleggende tillatelsene du nettopp har lest om, har Linux også et sett med avanserte tillatelser. Dette er ikke tillatelsene du angir som standard, men noen ganger gir de et nyttig tillegg. I denne delen lærer du hva de er og hvordan du setter dem opp.

Forstå SUID, GUID og Sticky Bit Extended Permissions

Det er tre avanserte tillatelser. Den første av disse er tillatelsen til å angi en brukeridentifikator (SUID). I noen spesielle tilfeller kan du bruke denne tillatelsen på kjørbare filer. Som standard kjører en bruker som kjører en kjørbar fil med sine egne tillatelser.

For vanlige brukere betyr dette vanligvis at bruken av programmet er begrenset. Men i noen tilfeller trenger brukeren spesielle tillatelser, bare for å utføre en spesifikk oppgave.

Tenk for eksempel på en situasjon der en bruker må endre passordet sitt. For å gjøre dette må brukeren skrive sitt nye passord til filen /etc/shadow. Denne filen er imidlertid ikke skrivbar av ikke-rootbrukere:

root@hnl ~]# ls -l /etc/shadow
----------. 1 root root 1184 Apr 30 16:54 /etc/shadow

SUID-tillatelsen tilbyr en løsning på dette problemet. Verktøyet /usr/bin/passwd bruker denne tillatelsen som standard. Dette betyr at når du endrer passordet, blir brukeren midlertidig root, noe som lar ham skrive til filen /etc/shadow. Du kan se SUID-tillatelsen med ls-l som s i en posisjon der du normalt forventer å se x for egendefinerte tillatelser:

[root@hnl ~]# ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 32680 Jan 28 2010 /usr/bin/passwd

SUID-tillatelsen kan se nyttig ut (og i noen tilfeller er den det), men samtidig er den potensielt farlig. Hvis det ikke brukes riktig, kan du ved et uhell gi bort root-tillatelser. Derfor anbefaler jeg å bruke den kun med største forsiktighet.

De fleste administratorer vil aldri trenge å bruke det; du vil bare se det i noen filer der operativsystemet skal sette det som standard.

Den andre spesielle tillatelsen er gruppeidentifikatoren (SGID). Denne tillatelsen har to virkninger. Når den brukes på en kjørbar fil, gir den brukeren som kjører filen tillatelsene til filens gruppeeier. Så SGID kan gjøre mer eller mindre det samme som SUID. SGID brukes imidlertid praktisk talt ikke til dette formålet.

Som med SUID-tillatelse, brukes SGID på noen systemfiler som standardinnstilling.

Når den brukes på en katalog, kan SGID være nyttig fordi du kan bruke den til å angi standard gruppeeier for filer og underkataloger opprettet i den katalogen. Som standard, når en bruker oppretter en fil, er deres effektive primærgruppe satt som gruppeeier for den filen.

Dette er ikke alltid veldig nyttig, spesielt siden Red Hat/CentOS-brukere har sin primærgruppe satt til en gruppe med samme navn som brukeren, og som brukeren er det eneste medlemmet av. Dermed vil filene som brukeren oppretter, som standard bli delt i bulk.

Se for deg en situasjon der brukere linda og lori jobber med regnskap og er medlemmer av en gruppe konto. Som standard er disse brukerne medlemmer av en privat gruppe som de er det eneste medlemmet av. Begge brukerne er imidlertid medlemmer av kontogruppen, men også som en sekundær gruppeparameter.

Standardsituasjonen er at når noen av disse brukerne oppretter en fil, blir den primære gruppen eieren. Derfor kan linda som standard ikke få tilgang til filer opprettet av lori, og omvendt. Men hvis du oppretter en delt gruppekatalog (si /groups/account) og sørger for at SGID-tillatelsen brukes på den katalogen og at gruppekontoen er satt som gruppeeier for den katalogen, vil alle filer som er opprettet i den katalogen og alle av underkatalogene , får også gruppekontoen som gruppeeier som standard.

Av denne grunn er SGID-tillatelsen en svært nyttig tillatelse å sette på offentlige gruppekataloger.

SGID-tillatelse vist i utdata ls-l som s på posisjonen der du normalt vil finne tillatelse til å utføre en gruppe:

[root@hnl data]# ls -ld account
drwxr-sr-x. 2 root account 4096 Apr 30 21:28 account

Den tredje av de spesielle tillatelsene er sticky biten. Denne tillatelsen er nyttig for å beskytte filer mot utilsiktet sletting i et miljø der flere brukere har skrivetilgang til samme katalog. Hvis en sticky bit brukes, kan en bruker bare slette en fil hvis de er brukereier av filen eller katalogen som inneholder filen. Av denne grunn brukes den som standardtillatelse for /tmp-katalogen og kan også være nyttig for offentlige gruppekataloger.

Uten den klebrige biten, hvis brukeren kan opprette filer i en katalog, kan de også slette filer fra den katalogen. I et offentlig gruppemiljø kan dette være irriterende. Se for deg brukerne linda og lori, som begge har skrivetillatelser til /data/kontokatalogen og får disse tillatelsene ved å være medlemmer av kontogruppen. Derfor kan linda slette filer opprettet av lori og omvendt.

Når du bruker den klebrige biten, kan brukeren bare slette filer hvis en av følgende betingelser er oppfylt:

• Brukeren er eieren av filen;
• Brukeren er eieren av katalogen der filen ligger.

Ved bruk ls-l, kan du se den klebrige biten som t i posisjonen der du normalt vil se utførelsestillatelse for andre:

[root@hnl data]# ls -ld account/
drwxr-sr-t. 2 root account 4096 Apr 30 21:28 account/

Bruk av utvidede rettigheter

For å bruke SUID, SGID og sticky bit kan du også bruke chmod. SUID har en numerisk verdi på 4, SGID har en numerisk verdi på 2, og sticky bit har en numerisk verdi på 1.

Hvis du vil bruke disse tillatelsene, må du legge til et firesifret argument til chmod, hvis første siffer refererer til spesielle tillatelser. Følgende linje vil for eksempel legge til SGID-tillatelse til katalogen og sette rwx for bruker og rx for gruppe og andre:

chmod 2755 /somedir

Dette er ganske upraktisk hvis du trenger å se gjeldende tillatelser som er satt før du arbeider med chmod i absolutt modus. (Du risikerer å overskrive tillatelser hvis du ikke gjør det.) Så jeg anbefaler å kjøre i relativ modus hvis du trenger å bruke noen av de spesielle tillatelsene:

1. For SUID-bruk chmod u+s.
2. For SGID-bruk chmod g+s.
3. For klebrig bruk chmod +t, etterfulgt av navnet på filen eller katalogen du vil angi tillatelser for.

Tabellen oppsummerer alt du trenger å vite om administrasjon av spesielle tillatelser.

Eksempel på arbeid med spesielle rettigheter

I dette eksemplet bruker du spesielle tillatelser for å gjøre det enklere for gruppemedlemmer å dele filer i den delte gruppekatalogen. Du tildeler ID-biten til den angitte gruppe-IDen så vel som den klebrige biten, og du ser at når de er satt, legges funksjoner til for å gjøre det lettere for gruppemedlemmer å jobbe sammen.

1. Åpne en terminal der du er linda-bruker. Du kan opprette en bruker med kommandoen brukerlegg til linda, legg til passord passwd Linda.
2. Opprett /data-katalogen i roten og /data/sales-underkatalogen med kommandoen mkdir -p /data/salg. Fullstendig cd /data/salgfor å gå til salgskatalogen. Fullstendig berør linda1 и berør linda2for å lage to tomme filer eid av linda.
3. Henrette su-lisa for å bytte gjeldende bruker til brukeren lisa, som også er medlem av salgsgruppen.
4. Henrette cd /data/salg og kjør fra den katalogen ls-l. Du vil se to filer som ble opprettet av linda-brukeren og tilhører linda-gruppen. Fullstendig rm -f linda*. Dette vil fjerne begge filene.
5. Henrette berør lisa1 и berør lisa2for å lage to filer som eies av brukeren lisa.
6. Henrette su- for å heve privilegiene dine til root.
7. Henrette chmod g+s,o+t /data/salgfor å angi gruppeidentifikatoren (GUID)-biten så vel som sticky-biten i den delte gruppekatalogen.
8. Henrette su-linda. Så gjør berør linda3 и berør linda4. Du skal nå se at de to filene du opprettet eies av salgsgruppen, som er gruppeeieren av /data/sales-katalogen.
9. Henrette rm -rf lisa*. Den klebrige biten forhindrer at disse filene blir slettet på vegne av linda-brukeren, siden du ikke er eieren av disse filene. Merk at hvis linda-brukeren er eieren av /data/sales-katalogen, kan de slette disse filene uansett!

ACL-administrasjon (setfacl, getfacl) i Linux

Selv om de utvidede tillatelsene diskutert ovenfor legger til nyttig funksjonalitet til måten Linux håndterer tillatelser på, tillater det deg ikke å gi tillatelser til mer enn én bruker eller gruppe i samme fil.

Tilgangskontrolllister tilbyr denne funksjonen. I tillegg lar de administratorer angi standardtillatelser på en kompleks måte, der de angitte tillatelsene kan variere fra katalog til katalog.

Forstå ACL-er

Selv om ACL-undersystemet gir god funksjonalitet til serveren din, har det én ulempe: ikke alle verktøy støtter det. Derfor kan du miste ACL-innstillingene når du kopierer eller flytter filer, og sikkerhetskopieringsprogramvaren kan mislykkes i å sikkerhetskopiere ACL-innstillingene.

Tar-verktøyet støtter ikke tilgangskontrollister. For å sikre at ACL-innstillingene ikke går tapt når du oppretter en sikkerhetskopi, bruk stjerne i stedet for tjære. stjerne fungerer med de samme alternativene som tjære; det legger bare til støtte for ACL-innstillinger.

Du kan også sikkerhetskopiere ACLer med getfacl, som kan gjenopprettes ved hjelp av setfacl-kommandoen. For å lage en sikkerhetskopi, bruk getfacl -R /katalog > fil.acls. For å gjenopprette innstillinger fra en sikkerhetskopifil, bruk setfacl --restore=fil.acl.

Mangel på støtte fra enkelte verktøy burde ikke være noe problem. ACL-er brukes ofte på kataloger som et strukturelt tiltak i stedet for på individuelle filer.
Derfor vil det ikke være mange av dem, men bare noen få, brukt på smarte steder i filsystemet. Derfor er det relativt enkelt å gjenopprette de originale tilgangskontrollistene du jobbet med, selv om sikkerhetskopieringsprogrammet ikke støtter dem.

Klargjør filsystemet for ACL-er

Før du begynner å jobbe med tilgangskontrollister, må du kanskje forberede filsystemet for å støtte tilgangskontrollister. Fordi filsystemmetadata må utvides, er det ikke alltid standardstøtte for ACLer i filsystemet. Hvis du får en melding om at "operasjon ikke støttes" når du konfigurerer tilgangskontrollister for et filsystem, kan det hende at filsystemet ikke støtter tilgangskontrollister.

For å fikse dette må du legge til alternativet acl-feste i /etc/fstab-filen slik at filsystemet er montert med ACL-støtte som standard.

Endring og visning av ACL-innstillinger med setfacl og getfacl

For å sette en ACL trenger du kommandoen setfacl. For å se gjeldende ACL-innstillinger trenger du getfacl. Team ls-l viser ingen eksisterende tilgangskontrollister; den viser bare et + etter tillatelseslisten, som indikerer at tilgangskontrollistene gjelder for filen også.

Før du setter opp ACL-er, er det alltid en god idé å vise gjeldende ACL-innstillinger med getfacl. I eksemplet nedenfor kan du se gjeldende tillatelser, som vist med ls-l, og også som vist med getfacl. Hvis du ser nøye nok etter, vil du se at informasjonen som vises er nøyaktig den samme.

[root@server1 /]# ls -ld /dir
drwxr-xr-x. 2 root root 6 Feb 6 11:28 /dir
[root@server1 /]# getfacl /dir
getfacl: Removing leading '/' from absolute path names
# file: dir
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

Som et resultat av å utføre kommandoen getfacl nedenfor kan du se at tillatelsene vises for tre forskjellige objekter: bruker, gruppe og andre. La oss nå legge til en ACL for å gi lese- og utføringstillatelser til salgsgruppen også. kommando for dette setfacl -mg:salg:rx /dir. I dette laget -m indikerer at gjeldende ACL-innstillinger må endres. Etter det g:salg:rx forteller kommandoen om å sette read-execute ACL (rx) for gruppen (g) salg. Nedenfor kan du se hvordan kommandoen ser ut, samt utdata fra getfacl-kommandoen etter å ha endret gjeldende ACL-innstillinger.

[root@server1 /]# setfacl -m g:sales:rx /dir
[root@server1 /]# getfacl /dir
getfacl: Removing leading '/' from absolute path names
# file: dir
# owner: root
# group: root
user::rwx
group::r-x
group:sales:r-x
mask::r-x
other::r-x

Nå som du forstår hvordan du setter opp en gruppe-ACL, er det lett å forstå ACL-er for brukere og andre brukere. For eksempel kommandoen setfacl -mu:linda:rwx /data gir tillatelser til linda-brukeren i /data-katalogen uten å gjøre den til eier eller endre tilordningen til den nåværende eieren.

Lag setfacl har mange funksjoner og alternativer. Ett alternativ er spesielt viktig, parameteren -R. Hvis det brukes, setter alternativet tilgangskontrollisten for alle filer og underkataloger som for øyeblikket finnes i katalogen der du angir tilgangskontrollisten. Det anbefales at du alltid bruker dette alternativet når du endrer tilgangskontrollister for eksisterende kataloger.

Arbeide med standard ACLer

En av fordelene med å bruke tilgangskontrollister er at du kan gi tillatelser til flere brukere eller grupper i en katalog. En annen fordel er at du kan aktivere arv ved å jobbe med standard ACL-er.

Ved å angi standard ACL, bestemmer du tillatelsene som skal angis for alle nye elementer som opprettes i katalogen. Vær oppmerksom på at standard ACL ikke endrer tillatelser på eksisterende filer og underkataloger. For å endre dem, må du legge til en vanlig ACL også!

Dette er viktig å vite. Hvis du vil bruke en ACL til å konfigurere flere brukere eller grupper for å få tilgang til samme katalog, må du angi ACL to ganger. Første bruk setfacl -R -mfor å endre ACL for gjeldende filer. Bruk deretter setfacl-md:å ta vare på alle nye elementer som også skal lages.

For å angi standard ACL trenger du bare å legge til alternativet d etter alternativ -m (rekkefølge betyr noe!). Så bruk setfacl -md:g:salg:rx /datahvis du vil at gruppesalg skal lese og utføre det som er opprettet i /data-katalogen.

Når du bruker standard ACLer, kan det også være nyttig å angi ACLer for andre. Dette gir vanligvis ikke mye mening fordi du også kan endre tillatelsene for andre som bruker chmod. Men hva du ikke kan gjøre med chmod, er å spesifisere rettighetene som må gis til andre brukere for hver ny fil som noen gang opprettes. Hvis du vil forhindre at andre får noen tillatelser på noe som er opprettet i /data, for eksempel bruk setfacl -md:o::- /data.

ACLer og normale tillatelser er ikke alltid godt integrert. Det kan oppstå problemer hvis du bruker en standard ACL på en katalog, deretter legges elementer til den katalogen, og deretter prøver å endre de vanlige tillatelsene. Endringer som gjelder vanlige tillatelser vil ikke reflekteres godt i ACL-oversikten. For å unngå problemer, angi normale tillatelser først, og deretter angi standard ACL-er (og prøv å ikke endre dem igjen etter det).

Eksempel på administrasjon av forhøyede rettigheter ved bruk av tilgangskontrollister

I dette eksemplet vil du fortsette med /data/account og /data/sales-katalogene du opprettet tidligere. I de forrige eksemplene har du sørget for at salgsgruppen har tillatelser på /data/salg og kontogruppen har tillatelser på /data/konto.

Først må du sørge for at kontogruppen får lesetillatelser i /data/salgskatalogen og at salgsgruppen får lesetillatelser i /data/kontokatalogen.

Du angir deretter standard tilgangskontrollister for å sikre at alle nye filer har de riktige tillatelsene for alle nye elementer.

1. Åpne en terminal.
2. Henrette setfacl -mg:konto:rx /data/salg и setfacl -mg:salg:rx /data/konto.
3. Henrette getfaclfor å sikre at tillatelsene ble satt slik du ønsket.
4. Henrette setfacl -md:g:konto:rwx,g:salg:rx /data/salgfor å angi standard ACL for salgskatalogen.
5. Legg til en standard ACL for /data/account-katalogen ved hjelp av setfacl -md:g:salg:rwx,g:konto:rx /data/konto.
6. Bekreft at ACL-innstillingene er i kraft ved å legge til en ny fil i /data/sales. Fullstendig trykk på /data/salg/nyfil og utføre getfacl /data/salg/nyfil for å sjekke gjeldende tillatelser.

Angir standardtillatelser med umask

Ovenfor lærte du hvordan du arbeider med standard tilgangskontrollister. Hvis du ikke bruker en ACL, er det et shell-alternativ som bestemmer standardtillatelsene du får: umask (omvendt maske). I denne delen lærer du hvordan du endrer standardtillatelsene med umask.

Du har kanskje lagt merke til at når du oppretter en ny fil, er noen standardtillatelser satt. Disse tillatelsene bestemmes av innstillingen umask. Denne shell-innstillingen gjelder for alle brukere ved pålogging. I parameter umask en numerisk verdi brukes, som trekkes fra de maksimale tillatelsene som kan angis automatisk for filen; den maksimale innstillingen for filer er 666 og for kataloger er 777.

Noen unntak gjelder imidlertid for denne regelen. Du kan finne en fullstendig oversikt over innstillinger umask i tabellen nedenfor.

Av tallene brukt i umask, som i tilfellet med numeriske argumenter for kommandoen chmod, det første sifferet refererer til brukerens tillatelser, det andre sifferet refererer til gruppens tillatelser, og det siste refererer til standardtillatelsene som er satt for andre. Betydning umask standard 022 gir 644 for alle nye filer og 755 for alle nye kataloger som er opprettet på serveren din.

Full oversikt over alle numeriske verdier umask og deres resultater i tabellen nedenfor.

En enkel måte å se hvordan umask-innstillingen fungerer på er som følger: start med filens standardtillatelser satt til 666 og trekk fra umasken for å få de effektive tillatelsene. Gjør det samme for katalogen og standardtillatelsene 777.

Det er to måter å endre umask-innstillingen på: for alle brukere og for individuelle brukere. Hvis du vil angi umask for alle brukere, må du sørge for at umask-innstillingen tas i betraktning når du starter skallmiljøfiler, som spesifisert i /etc/profile. Den riktige tilnærmingen er å lage et skallskript kalt umask.sh i /etc/profile.d-katalogen og spesifisere umasken du vil bruke i det skallskriptet. Hvis umasken endres i denne filen, brukes den på alle brukere etter å ha logget på serveren.

Et alternativ til å sette umask via /etc/profile og relaterte filer, der det gjelder for alle brukere som logger på, er å endre umask-innstillingene i en fil kalt .profile som opprettes i hver brukers hjemmekatalog.

Innstillingene som brukes i denne filen gjelder kun for den enkelte brukeren; derfor er dette en god metode hvis du trenger flere detaljer. Jeg personlig liker denne funksjonen for å endre standard umask for root-brukeren til 027 mens normale brukere kjører med standard umask på 022.

Arbeid med utvidede brukerattributter

Dette er den siste delen om Linux-tillatelser.

Når du arbeider med tillatelser, er det alltid et forhold mellom et bruker- eller gruppeobjekt og tillatelsene som bruker- eller gruppeobjekter har på en fil eller katalog. En alternativ metode for å beskytte filer på en Linux-server er å jobbe med attributter.
Attributter gjør jobben sin uavhengig av brukeren som har tilgang til filen.

Som med ACL-er, kan det hende filattributter må inkludere alternativet montere.

Dette er et alternativ user_xattr. Hvis du får meldingen "operasjon ikke støttet" når du arbeider med utvidede brukerattributter, må du passe på å angi parameteren montere i /etc/fstab.

Mange attributter er dokumentert. Noen attributter er tilgjengelige, men ikke implementert ennå. Ikke bruk dem; de vil ikke gi deg noe.

Nedenfor er de mest nyttige egenskapene du kan bruke:

A Dette attributtet sikrer at filens filtilgangstid ikke endres.
Vanligvis, hver gang en fil åpnes, må filens tilgangstid registreres i filens metadata. Dette påvirker ytelsen negativt; så for filer som blir åpnet regelmessig, attributtet A kan brukes til å deaktivere denne funksjonen.

a Dette attributtet lar deg legge til, men ikke fjerne, en fil.

c Hvis du bruker et filsystem som støtter volumnivåkomprimering, sikrer dette filattributtet at filen komprimeres første gang komprimeringsmekanismen aktiveres.

D Dette attributtet sikrer at endringer i filer skrives til disk umiddelbart i stedet for å bufres først. Dette er en nyttig egenskap på viktige databasefiler for å sikre at de ikke blir borte mellom filbufferen og harddisken.

d Dette attributtet sikrer at filen ikke blir lagret i sikkerhetskopier der dump-verktøyet brukes.

I Dette attributtet muliggjør indeksering for katalogen der det er aktivert. Dette gir raskere filtilgang for primitive filsystemer som Ext3 som ikke bruker B-tree-databasen for rask filtilgang.

i Dette attributtet gjør filen uforanderlig. Det kan derfor ikke gjøres endringer i filen, noe som er nyttig for filer som trenger ekstra beskyttelse.

j Dette attributtet sikrer at filen på et ext3-filsystem først skrives til journalen og deretter til datablokker på harddisken.

s Overskriv blokkene der filen ble lagret til 0s etter sletting av filen. Dette sikrer at en fil ikke kan gjenopprettes når den først er slettet.

u Dette attributtet lagrer informasjon om slettingen. Dette lar deg utvikle et verktøy som fungerer med denne informasjonen for å redde slettede filer.

Hvis du vil bruke attributtene, kan du bruke kommandoen skravling. Bruk for eksempel chattr +s en eller annen filå bruke attributter til en fil. Trenger du å fjerne et attributt? Bruk deretter chattr -s en eller annen filog den vil bli fjernet. For å få en oversikt over alle attributter som brukes for øyeblikket, bruk kommandoen lsattr.

Oppsummering

I denne artikkelen lærte du hvordan du arbeider med tillatelser. Du leser om de tre grunnleggende tillatelsene, avanserte tillatelsene og hvordan du bruker ACL-er på et filsystem. Du har også lært hvordan du bruker umask-alternativet til å bruke standardtillatelser. På slutten av denne artikkelen lærte du hvordan du bruker brukerutvidede attributter for å bruke et ekstra lag med filsystemsikkerhet.

Hvis du likte denne oversettelsen, vennligst skriv om den i kommentarene. Det vil være mer motivasjon til å lage nyttige oversettelser.

Rettet noen skrivefeil og grammatiske feil i artikkelen. Redusert noen store avsnitt til mindre for bedre lesbarhet.

I stedet for "Bare noen med administrative rettigheter til katalogen kan bruke utføringstillatelse." fikset til "Bare noen med skriverettigheter på katalogen kan bruke utføringstillatelse.", som ville være mer korrekt.

Takk for kommentarene berez.

Erstattet:
Hvis du ikke er eieren av brukeren, vil skallet sjekke for å se om du er medlem av en gruppe, også kjent som gruppen til filen.

På:
Hvis du ikke er eieren av filen, vil skallet sjekke om du er medlem av en gruppe som har tillatelser til filen. Hvis du er medlem av denne gruppen, vil du få tilgang til filen med tillatelsene som gruppen har angitt, og skallet vil slutte å sjekke.

takk for kommentaren din CryptoPirate

Kilde: www.habr.com