Indledning

Jeg har set nogle forkerte oplysninger om Unix filtilladelser. Jeg vil forsøge at sætte rekord lige. Tag et kig på dette eksempel på nogle uddata fra ls:
På den første linje, siger, at "rod", at biblioteket er ejet af brugeren kaldet "root". Og at "bin" er den gruppe af biblioteket. Du bliver nødt til at forstå brugere og grupper, og jeg vil antage, at du gør. Mit mål er at forklare, at "drwxrwxr-x" og "-r-xr-xr-x" stuff. Dette felt er en kombination af filtypen og adgang tilladelse. Kollektivt, disse oplysninger kaldes undertiden file mode. Og sommetider er det såkaldte permissions. Et godt sted at starte er ved at tage et hurtigt kig på, hvordan denne information er faktisk lagres på disken. Den måde, det er gemt berører en række beslutninger, der er foretaget i årenes løb.

Hvordan "File Mode" er gemt.

På disken, er oplysninger om en fil er gemt i struktur, der kaldes en "inode". Hver fil vil have det selv inode. Et dataelement i en inode kaldes "mode", og det ser sådan ud:
Jeg tror, at den "mode" egentlig betyder bare de tilladelser, og at den filtype blev skubbet på for at spare plads. Men forfatteren til ls programmet er at behandle tilstanden som et enkelt element. Det er grunden til filtypen er det første tegn i tilladelsen streng i "ls-l" output. Den filtype, vil der normalt være en af de syv typer, som jeg vist ovenfor. Nogle versioner af Unix vil tilføje et par mere. Den eneste anden ting at bemærke fra de data, layout er, at der ikke er plads til at tilføje flere tilladelse bits.

Repræsenterer disse tilladelser i oktale

Den ls Programmet kan vise, siger, "rwxrwxrwx" for tilladelser på en fil. Det er også meget almindeligt at bruge en oktale tal til at udtrykke de tilladelser på en fil. Og som du ser ovenfor, det er sådan, de er gemt. Du kan høre nogen sige, at nogle har 777 tilladelser. Dette er det samme som "rwxrwxrwx" og meget nemmere at udtale. Så du behøver at vide, hvordan man konverterer dem. Tre binære cifre eller bit svarer til en oktale ciffer:

Så "læse lidt værd 4, skrive lidt er værd 2 og udføre smule er værd 1. Du skal bare tilføje disse op for at få en oktale cifre. So"-rwxrwxrwx "er 777. Og"-rwxr-x -- - "er 750. Hvis du stadig ikke kan se, hvordan man kommer fra" rx "til 5, måske denne tabel vil hjælpe:

Bemærk, vi har brug for 4 oktale cifre til at udtrykke alle de tilladelse bits. De første tre bits er specielle og ofte nul. Og du næsten altid lære mere om den efterfølgende 9 bit først. Nogle mennesker stoppe der, og aldrig lære de første tre bits. Men der er 12 tilladelse bits, ikke kun 9. Når det er sagt, lad os nu tage et kig på den efterfølgende 9 bit.

Den Grundlæggende Permission Bits

Vi har 3 tripler: en tredobbelt for brugeren, en tredobbelt for gruppen, og en tredobbelt for andre. Undertiden "bruger" kaldes ejer. Og nogle gange "andre" kaldes "verden". Jeg vil bruge "bruger" og "andre", fordi kommandoen chmod bruger bogstaverne ug og o at henvise til disse tripler.

Hvilket sæt Bits gælder for dig?

Når Unix bestemmer, hvad du kan gøre, er det ikke bruger alle 9 bits. Unix henter den første tredobbelt der gælder for dig. Overvej dette: Selv om Joe ejer denne fil, kan han ikke få adgang til det. (Da Joe ejer filen, kunne han give sig adgang. Mere om det senere.) Også rod er speciel. root ydes rwx til alle mapper og RW til alle filer. På en fil, hvis nogen af de 3 x bits er fastsat root har køretilladelse. Denne særlige tilladelse er ofte handicappede på nettet monterede filsystemer.

Hvad gør rw og x egentlig for en fil?

For en fil, læses "og" skriver "er ret intuitive. X for "execute" betyder, at kernen kan forsøge at køre filen. For at arbejde, skal filen være en eksekverbar fil (output fra en compiler) eller et shell script med "#!" første linje. For en mappe, er tingene lidt mere kompliceret. Med et bibliotek, skal du skrive "" tilladelse betyder, at du kan oprette nye filer i den mappe, eller fjerne gamle filer. Det til tider overrasker folk, at du kan fjerne en fil, som du ikke kan læse. UNIX-kommandoen rm vil teste for det og udstede en advarsel, men du kan undertrykke denne advarsel med-f. Og advarsel eller nej, hvis du ønsker at fjerne en ulæselig fil fra en skrivbar mappe, du kan. Og rmdir vil ikke gider at se på alle.

Hvad gør rw og x virkelig betyde for et bibliotek?

Et bibliotek er en fil for, og "læse" lov betyder, at du kan læse den. Men du kan virkelig ikke gøre ret meget uden x tilladelse samt. Med mapper, du normalt har både læse og køretilladelse eller ingen af delene. På et bibliotek, x, der er officielt kaldes "søge tilladelse". Du har brug for x til at bruge et bibliotek i en sti. Så hvis du skriver "cat / etc / passwd", skal du x på / og / mv Du skal også bruge x til cd i en mappe. Antag, at du har læst, men ikke søgning (x) tilladelse på et bibliotek. Hvad kan du gøre? Ikke meget. Du kan bruge "ls" for at se filnavne. Selv "ls-l" ikke vil arbejde. Læs adgang uden at søge tilladelse er ikke meget nyttig. Stadig, der er bedre end kun at have lov til at skrive på et bibliotek ... der er fuldstændig ubrugelig. Jeg har ikke set nogen anden dokumentation, der hedder det udtrykkeligt, så lad mig gentage det: at skrive, men ingen køretilladelse på en mappe tilskud ingenting all.Suppose du har søgning (x) tilladelse, men ingen læsetilladelse på et bibliotek. Nu kan du åbne filerne i mappen, hvis du kender filens navn. Du kan cd i mappen. Og det er det. Du kan ikke engang oprette en ny fil. Tilføjelse skrivetilladelse vil tillade dig at oprette filer. Og du kan derefter slette filer, hvis du kender deres navn.

Symbolske link Special

Tilladelses indstillingerne på et symbolsk link er en lidt speciel også. De er fuldstændig ignoreret. Mange versioner af Unix har nogen måde at ændre dem.

SETUID og setgid Bits

Tag et kig på dette: Passwd fil er skrivbar kun ved roden (Husk, at roden er speciel. Det kan skrive en fil, der ikke har nogen skrive sæt tilladelser). Skyggen fil, som er hvor passwords er gemt, kan ikke engang kan læses af almindelige brugere. Men Joe ønsker at ændre sit password. Han kan gøre det ved at køre / usr / bin / passwd. Notice de rs tilladelser. Passwd program har de suid og SGID bits sæt. Dette slår x's i s's. I oktal, ville det være 6.555. Passwd program er ejet af root. Når Joe kører det, er det ikke køre som "Joe". I stedet, den kører som den ejer, der er roden. Så passwd program kan ændre Joe's adgangskode for ham. Den SGID bit virker på samme måde, bortset fra det forårsager passwd program til at køre med den gruppe sys i stedet for Joe's gruppe. Den suid og SGID ikke får deres egen position i ls. Når suid bit er sat, ls vises som snarere end økse for ejeren køretilladelse. Hvad hvis suid bit er indstillet, men ejeren udføre bit er slukket? ls vil vise en kapital S i sagen. Den SGID bit vises på samme måde, bortset fra at det interagerer med gruppen køretilladelse. (Sættet uid konceptet blev opfundet af Dennis Ritchie, som han var ved at udvikle Unix.)

At uddybe det lidt, mens Joe kører suid-til-root passwd program, "Joe" er den virkelige uid og "root" er den effektive uid. Passwd program kan få begge disse id's, hvis det vil. Dette er, hvordan passwd programmet ved at tillade Joe kun at ændre Joe's adgangskode.

Den Sticky Bit

Den POSIX standard, siger, at hvis den klistrede bit er sat på et bibliotek, blot skriverettigheder på biblioteket er ikke længere nok til, at filer, der skal fjernes. Du skal desuden egen filen eller egen biblioteket. root fortsætter med at kunne slette fra en mappe uanset tilladelser. Tidligere denne bit tjent et andet formål. På nogle OS er det stadig ikke. Jeg vil uddybe i et bilag nedenfor. Den klæbende bit påvirker de "andre" execute bit i ls vise. Bortset fra, at det bruger T og T i stedet for s og S. For eksempel: I denne / tmp folder ovenfor, kan man oprette nye filer. Men på grund af den klæbrige bit, kan en bruger ikke slette en brugers filer.

Begrænsning filtilladelser med umask

Når filerne er skabt det program, der skaber kan angive den oprindelige tilladelse, der fastlægger. Du kan tilsidesætte denne med umask. Den umask er et sæt af forbud bits. Der er en umask kommando der giver dig mulighed for at se og ændre umask. For eksempel forbyder "umask 022" gruppe skrive og andre skrive om nyoprettede filer. Eller "umask 027" forbyder gruppe skrive, og det forbyder andre læse, skrive, eller udføre. Du kan lave en "umask 0" for at lade programmet gøre, hvad det ønsker, da det skaber programmer. Men du kan ikke gå videre. Du kan ikke tvinge et program til at slå lidt på. Den umask indstilling påvirker filer, mapper, navngivne pipes (alias FIFOs), og specielle filer. Det kan eller ikke kan påvirke symbolske links. Det påvirker også legeme former for Interproceskommunikation men det er uden for rammerne af denne artikel. Og tro det eller ej, opkaldt stikkontakter er undtaget fra umask. Denne undtagelse er påkrævet ved POSIX.

Ændring af filtilladelser med chmod

Kun ejeren af en fil eller root kan ændre tilladelser på en fil. Denne operation er ikke påvirkes på alle af umask indstilling. Hvis du ændrer tilladelserne på et symbolsk link, vil forbindelsen blive fulgt, og du vil ændre målet fil. Det er muligt, at kun root vil have beføjelse til at fastsætte en fils klæbrig smule. Som et eksempel, chmod "700 somefile" wil lade ejeren læse, skrive og køre filen, samtidig med at forbyde alle adgang til alle andre brugere.

Brug Symbolic Mode med chmod og umask

POSIX indført en ny syntaks for kommandoen chmod. Tanken var, at den nye syntaks vil erstatte brugen af en oktale konstant med kommandoen chmod. Oktal konstant er stadig tilladt, og jeg tror det er kommet for at blive. Men den nye symbolsk syntaks, kan du ændre et par stykker uden at vide hvad de andre. For eksempel, lad os sige, at jeg vil lave en fil utilgængelig for andre, men jeg ved ikke hvad de skal ændre acess for brugeren eller gruppen. Jeg vil være nødvendigt at gøre:
ls-l-fil
Kig på filen og finde ud af de aktuelle indstillinger.
chmod 750 file
Jeg var nødt til at fastslå, at de første to cifre er strømninger 7 og 5, før jeg kunne gøre mit kommandoen chmod. Med den nye syntaks, kan jeg simpelthen gøre:
chmod o \u003d file
at slukke for de sidste 3 bits. Som et andet eksempel, chmod "u + x fil" vil gøre det muligt for brugeren at køre filen. På den anden side er disse to kommandoer svarer:
chmod 750 file
chmod u \u003d rwx, g \u003d rx, o \u003d fil
og jeg foretrækker den første syntaks.

Den symbolske tilstand kan være en kommasepareret liste af specifikationer. Hver specifikation har tre komponenter: <who> <operation> <bitlist> X er det samme som x, medmindre filen er en nondirectory og har i øjeblikket ingen x bits sæt. S (sæt uid eller sæt gid) kan kun specificeret for bruger eller gruppe tilladelser. De t kan kun specificeret for brugertilladelser. Et par eksempler med hjælp. Over så vi / usr / bin / passwd var 6555 (-r-sr-sr-x i ls). Her er nogle måder, der kunne opnås:
chmod 6.555 / usr / bin / passwd
chmod u \u003d RXS, g \u003d RXS, o \u003d rx / usr / bin / passwd
chmod ug \u003d RXS, o \u003d rx / usr / bin / passwd
chmod a \u003d rx, ug + s / usr / bin / passwd
Og der er mange andre måder at gøre dette.

For det meste chmod er immun over for umask i, at uanset hvad bits det ønsker at sætte får ikke ændret ved umask. Men, på én betingelse, vil kommandoen chmod undersøge den aktuelle indstilling af umask at afgøre, hvilke bits det ønsker at fastsætte. Dette sker, når du forlader "som" tomt. Sådan her:
chmod \u003d w somefile
Forskellen mellem "a \u003d w" og "\u003d w" er subtil. Her er et eksempel, der kan hjælpe. Mange programmer forsøger at oprette filen med 666 (-rw-rw-rw-) tilladelser. Men dette bliver ændret i det umask. Antag, at du ønsker at indstille en fil til 666, men modificeret af den nuværende umask. Vi kunne slukke alle bits, tænd derefter læse og skrive bits, der er tilladt af den nuværende umask:

chmod a \u003d, \u003d RW somefile

Og taler om umask, kan du bruge symbolske argumenter med umask styring samt. Men, POSIX, I deres visdom besluttet, at der i dette tilfælde at logik ville blive tilbageført. Så hvis brug umask med en oktale argument, du angiver de bits, der skal forbydes. Men hvis du bruger umask med en symbolsk argument, du angiver bits til at tillade. Så disse svarer:
umask 022
umask u \u003d rwx, go \u003d rx

Resumé

På dette punkt du har nok oplysninger til at det meste forstå disse 12 tilladelse bits. Der er flere meget specielle tilfælde, at jeg har ignoreres eller ties ihjel. I særskilte stillinger nedenfor Jeg vil behandle disse. Oplysningerne i dette første indlæg er stort set universel. En POSIX kompatibel OS skal støtte det her. , Som dækker næsten alle versioner af Unix udgivet i de seneste 10 år. De følgende artikler drøfte funktioner, der kan ikke være universel.

Jeg tidligere har nævnt, at når et bibliotek har klistret bit sat, kan en fil slettes kun af ejeren af filen eller ejeren af mappen. Denne opførsel er angivet af POSIX og er nu temmelig universel. Men det var ikke det oprindelige formål med den klæbende smule. Jeg kan se, at POSIX definition af de ls kommandoen faktisk opfordrer den klistrede smule "begrænset sletning flag". Den konstante i C-header-filer til denne smule er S_ISVTX. Den svtx står for gemme tekst og dette viser det oprindelige formål med den smule.

Den oprindelige idé var, at hvis den klistrede smule var der, ville teksten segment af en proces ophold i swap-område. Dette vil gøre det muligt at blive læst ind i hukommelsen med en enkelt disk læse. Oprindeligt, Unix brugt et filsystem med en blok størrelse på 512 og blokerer en tendens til at sprede. Så det ville tage tid at hente teksten segment og indlæse den i hukommelsen. I første omgang var der ingen personsøgning, kun swapping. Og at køre et program vil være nødvendigt at være helt indlæst i hukommelsen. Nu vi side-fejl et program i hukommelsen. Sider indlæses som de er nødvendige. Så er den oprindelige brug af den klistrede lidt død? Nå, nej. Det afhænger af OS.

Med HP-UX, er denne anvendelse stadig er i live og er dokumenteret på HP-UX chmod (2) man-siden. Hvad nytter det? Fra HP-UX Kerne Tuning and Performance Guide via HP-UX Faq:
"Når ansøgningerne er placeret eksternt, indstille" sticky bit "om ansøgningerne binære filer, bruger chmod + t kommando. Dette fortæller systemet til side i teksten på den lokale disk. Ellers er det" hentes "på tværs af netværket. Of Naturligvis vil dette kun gælde, når der er en reel personsøgning forekommende. For nylig er der en kerne parameter, page_text_to_local, som når den er indstillet til 1, vil fortælle kernen til side alle NFS eksekverbare tekstsider til lokale swap-plads. "

Med Solaris, er der ingen tegn på den oprindelige brug af den klæbrige smule, men ifølge Solaris chmod (2) man-siden:
"Hvis en almindelig fil ikke er eksekverbar, og har S_ISVTX sæt, filen antages at være en swap-fil. I dette tilfælde, vil systemets side cache ikke bruges til at holde filens data. Hvis S_ISVTX bit er sat på noget andet fil, resultaterne er uspecificeret. "

Så du bliver nødt til at tjekke chmod (2) man-siden for netop dit OS for at se, hvilken effekt, om nogen, den klæbrige bit har på en fil. Også være opmærksom på, at når en effekt eksisterer, kan den OS begrænse fastsætte en klæbrig smule til roden. For eksempel, med HP-UX, en ondsindet bruger kan indstille en masse klistret bits og køre systemet ud af swap-plads.

HP-UX faktisk også har nogle symbolske links, der har den klæbende bit sat. Jeg vil tage dette nedenfor.

Vi kort nævnes, at filer har en bruger og gruppe med tilknytning til dem. Oprindeligt var det kun brugeren og gruppen af hvem der har skabt dem. Men oprindeligt, kan en bruger være i kun én gruppe ad gangen. BSD indført begrebet, at en bruger kan være i flere grupper simutaneously. Så i BSD, hvilken gruppe der blev brugt? BSD besluttet at anvende den gruppe af den mappe, der indeholder den nyoprettede fil.

Mange moderne versioner af Unix forsøge at få det på begge måder. En nyoprettet fil får den gruppe af brugeren, medmindre bibliotek har setgid smule. I så fald får den nyoprettede fil gruppen af biblioteket.

Og der er en undtagelse til denne! Ændring af ejeren eller gruppe af en fil, der er sikkerhedsproblemer. Af denne grund vil nogle versioner af UNIX, valgfrit, forbyde en anden bruger end rod i at ændre ejeren af en fil. Desuden en bruger er forbudt at ændre den gruppe af en fil, medmindre han er medlem af den nye gruppe. Denne begrænsning vil tilsidesætte setgid smule på et bibliotek, hvis nødvendigt.

Vi er ikke færdige med at Indstil Gid lidt endnu ... Unix er et koncept af fillåsning. Fillåsning ligger uden for denne tråd. Men du skal vide, at fillåsning kommer i to varianter: rådgivende og manditory. Hvilken smag refererer til en bestemt fil, afhængigt af tilladelse indstillinger. Hvis gruppen udføre smule er slukket, men setgid bit er tændt, enhver fil låse på, at filen er manditory.

Ubrugelig Bit kombination?

Hver henvisning, at jeg har set, siger, at setgid på / gruppe køre off er en anden måde ubrugeligt kombination. Selv Richard Stevens (i Avanceret programmering i Unix-miljø) Siger: "Da det sæt-gruppe-ID bit giver ingen mening, når den gruppe-execute bit er slukket, designere af SVR3 valgt denne måde at præcisere, at låsning af en fil skal maditory låsning og ikke rådgivende låsning."

Godt overveje denne sag: Fred kører Human Resources afdeling. Fred og hans gruppe ofte nødvendigt at opslag de feriedage, der anvendes til de ansatte. Fred beslutter sig for at skrive et program, så medarbejderne kan lookup deres egen ferie anvendes dage. For sikkerhed, gør Fred dette program gøre en masse for skovhugst. Fred beslutter, at han ikke ønsker sin gruppe, at bruge dette program. De har andre værktøjer, der ikke vil rode hans log. Så Fred gør:
chown fred: hr vdays
chmod 2701 vdays
Nu vdays programmet kan ikke køres af medlemmer af HR (undtagen fred). Men det kan køres af alle andre. Og det vil påtage sig det gid af hr, når det ikke kører. Jeg har skrevet et testprogram, der er det op på denne måde, og har kørt det på både Solaris og HP-UX. Det virker.

Effekt på ls output

Selv om denne smule kombination kan være nyttig, er visse begrænsede tilfælde, for bedre eller værre, vil det have to effekter. Den vdays programmet virker, men hvis en lås er forsøgt på den fil, vil det være manditory. Som et praktisk anliggende, vil denne virkning kun lejlighedsvis program som en debugger. Men ls kan behandle denne kombination smule anderledes. Jeg har set begge disse ...

Symbolske links har udviklet sig over årene. Ved første, et symbolsk link fulgte kun, når du åbner en fil. Altså:
touch datafile
ln-s datafile luske
chmod 700 luske
ikke beskytte fil kaldet "datafile". Det var et sikkerhedsproblem. I dag, at "chmod 700 luske" vil ændre tilladelserne på datafile. "chown fred datafil" vil også ændre datafil og lad luske alene.

Symbolske links skal have en ejer

Der er en måde at ændre ejeren af et symbolsk link. Det er "chown-h luske". Dette vil ændre luske og lad datafile alene. Den oprindelige grund til, at symbolske links brug for en ejer er en funktion, der hedder "kvoter". Kvoter giver systemet mulighed for administrationen til at begrænse den diskplads, der anvendes af en bruger. En symbolsk link bruger en lille mængde af disken ressourcer, så det må blive opkrævet for brugeren. Vi har nu en anden grund: klæbrige mapper. Vi har brug for at vide, hvem der kan fjerne et symbolsk link fra en klæbrig bibliotek.

Ud over at en ejer, POSIX kræver, at symbolsk link har en størrelse. Det er alt, du kan stole på. Symbolske links måske ikke engang har en tilladelse bits.

Permission Bits er nødvendige af POSIX at blive ignoreret

På Solaris og Linux, nyoprettede symbolske links er 777, og det er ikke påvirket af umask. Jeg kunne ikke ikke finde nogen måde at slå bit off. På HP-UX, er symbolske links også skabt med 777, men umask påvirker dette. Altså:
umask 777
ln-s datafile luske
skaber en symbolsk link med alle de bits slukkes. Dette havde ingen effekt på alt, hvad jeg kunne gøre med datafile. Og symbolsk link (med en tilstand af 0) til mapper også fungeret fint.

BSD Har en måde at ændre Tilladelse Bits på et symbolsk link

De forskellige BSD distributioner har alle en "chmod-h", som er ligesom den nødvendige "chown-h". Brug denne kommando jeg testede symbolske links på FreeBSD og fundet, at de ignorerer tilladelse bits også. Den "chmod-h" kommando er gennemført ved hjælp af en lchmod () system opkald. (BSD selv har en lutimes () system opkald og en "touch-h" kommando til at påberåbe sig det.) Så langt så godt. Intet her er overtræder POSIX standard.

NetBSD Kan være at overtræde POSIX Standard

Ifølge de NetBSD symlinket Manden side: "De readlink (2)-systemet opkald kræver læserettigheder på det symbolske link." readlink () er det system, opkald bruges af ls at vise målet om et symbolsk link. Så med noget som dette: som datafile blev opnået med readlink (). Jeg har ikke adgang til en NetBSD system til test, så jeg kunne ikke bekræfte dette.

HP-UX Transition Links

Når HP omskrev HP-UX at opfylde System V Release 4, placeringen af masser af ændrede filer. Som et eksempel, flyttede mine foretrukne shell fra / bin / ksh til / usr / bin / ksh. Nogle mennesker stadig bruger / bin / ksh og som vil arbejde (for nu) på grund af et symbolsk link:
Hvordan er HP tænde for at sticky bit? Den lchmod () system opkald er blevet lånt fra BSD. Dette er en udokumenteret funktion i HP-UX. HP's idé er, at de kan være sikker på, at en klæbrig symlink ikke blev oprettet af brugere, fordi brugerne ikke kender lchmod. Brug lchmod () for at tænde den klæbende smule ikke ændrer egenskaberne for den symbolske på nogen måde. Den eneste forskel er, at HP's tl værktøjer vil være villige til at operere på den symbolske.

Men her er hvad den HP-UX faq har at sige: "Overgang links er en smule hurtigere, fordi den er knyttet til filnavn er lagret i inode sig selv, i stedet for at bruge en tildeling enhed til at gemme linket. "Selv om dette udsagn er ikke helt forkert, det er frygtelig misvisende. HP-UX blot understøtter hurtig symlinks. Hvis der refereres til filnavnet er kort nok, det er lagret direkte i inode. Overgangen links ske skal være kort nok. Jeg har set nogle mennesker bruger lchmod () for at tænde den klæbende lidt af en symbolsk i et forsøg på at fremskynde tingene. Det virker ikke sådan.

Overgang links er begyndt at forsvinde. Folk, der ikke har skiftet fra / bin / ksh til / usr / bin / ksh en dag kan få en grov overraskelse. Nedenfor er nogle links til HP's hjemmeside.

Fastholdelse Transition Links
Transition Links kommandoer (Deprecated)
Transition Links (Deprecated)

Vi har diskuteret, hvordan skriverettigheder styrer evnen til at ændre data i en fil. Men hvad med at ændre tilladelse bits, ejeren, gruppen, og selv tidsstempler? Ingen kan ændre noget på en cd og en NFS server kan underkende en NFS klient. I den efterfølgende diskussion, vil jeg gå ud fra en lokal læse-skrive filsystem, og at den bruger kaldet "root" er passende særlige administrative privilegier til filsystemet i spørgsmålet.

chmod - Ændring af filtilladelser

At ændre filrettigheder på alle, skal du være ejer af filen, eller du skal være root brugeren. Root-brugeren kan ændre enhver tilladelse smule. Det kan ikke være rigtigt af ejeren. Den en smule, at ejeren ikke kan være i stand til at tænde er SGID smule.

At tænde for den smule, skal ejeren være medlem af gruppen, at filen er i. Hvis denne begrænsning var ikke på plads, kan en bruger skal du blot oprette en SGID program til at give sig selv adgang til filer, som kontrolleres af andre grupper end dem, som han tilhører. Husk, at, som vi nævnte ovenfor, har SGID smule er ofte overbelastet i også kan anvendes til fillåsning. En version af Unix måske eller måske ikke vil tillade en fil ejeren til at tænde SGID lidt af en fil i en anden gruppe, hvis der ikke udføre bit er sat.

Du skal blot tænde for en fuldbyrde smule kan resultere i SUID og SGID bit, der ryddet (også for root). Dette er en sikkerhedsfunktion for at sikre, at brugeren har til hensigt til SUID og SGID bits, der skal fastsættes. Brugeren kan skifte dem tilbage på eksplicit. Eller brugeren kan simpelthen eksplicit indstille alle smule på én gang. Også være klar over, at skrive til en fil, kan på nogle versioner af Unix, klar SUID og SGID bits. Se nedenfor for effekten af skiftende ejeren eller gruppe af en fil.

chown - Ændring af filejeren

Oprindeligt Unix have en fil ejeren at give væk en fil. En fil ejer kunne ændre ejer til en anden. Der var ingen vej for en ikke-root-bruger til at fortryde denne operation. Når Unix opdelt i Berkeley / AT & T versioner, USG (Unix Support Group, en del af AT & T) versioner af Unix tendens til at arve dette problem. I mellemtiden BSD (Berkeley Software Distribution, en del af University of California, Berkeley) fjernet chown fra ikke-root-brugere. BSD havde gennemført diskkvotaer, som kan begrænse, hvor meget diskplads en bruger kunne få i et filsystem. Naughty brugere kunne give nogle store filer til Sneek forbi kvoter.

Dag, er det ikke let at sige, hvis en ikke-root kan chown en fil. Mange versioner af Unix tillade begge adfærd. HP-UX har en setprivgroup facilitet der kan kontrollere, om der ikke er medlemmer af en bestemt gruppe, kan påberåbe chown. Solaris er en global parameter rstchown som kan indstilles til at tillade de globale chown. Indstilling af denne parameter også deaktiverer en ændring-gruppe begrænsning beskrevet nedenfor (uden at det påvirker SGID begrænsninger beskrevet ovenfor). Nyere Linux-versionen har en CAP_CHOWN evne til at kontrollere denne funktion. Du bliver nødt til at konsultere din dokumentation til andre versioner af Unix. Og du skal kontakte din systemadministrator for at se, hvordan netop dit system er konfigureret.

Den standard med de fleste OS'er er chown at være begrænset til kun som root. Og der er enighed om, at det skal forblive på denne måde for sikkerheden. Hvis en ikke-root-brugeren ændrer ejeren af en fil og enhver effektuere bit er tændt, skal SUID og SGID bits blive ryddet. Dette kan eventuelt ske med rod.

chown, chgrp - Ændring Fil-Gruppen

Det chown Kommandoen kan (med en moderne, POSIX kompatibel version af Unix) også forsøge en gruppe forandring. Og der er en chgrp kommando. Begge disse påberåbe sig chown () system opfordring til at ændre en gruppe. Den omstændighed, at et fælles system opkald er involveret hjælper med at forklare, hvorfor nogle OS versioner fællesskab håndhæve eller lempe reglerne for ikke-root-brugere for både ejer og gruppe ændringer.

En ikke-root-bruger kan ændre den gruppe af filen han ejer til en gruppe, som han er medlem af. POSIX forbyder en ikke-root-brugeren i at ændre en gruppe filer til en gruppe, som han ikke er medlem. Men nogle OS'er ophæve denne begrænsning, hvis begrænsning i forhold til at ændre en fil's ejer er blevet ophævet.

Hvis gruppen er ændret af en ikke-root-bruger og en eller udføre bits er indstillet, SUID og SGID bits er ryddet.

touch - Changing Fil timestamps

Når touch kommando bruges til at ændre tidsstempler af en eksisterende fil, den påberåber sig enten den gamle utime () eller den nye utimes () system opkald. At ændre tidsstemplet på en eksisterende fil, skal du ejer filen eller være root. Også skal du have lov til at skrive på den fil eller være root.