The UNIX and Linux Forums  
Hei og Velkommen fra USA til UNIX og Linux Forums! Takk for besøket og Delta i vårt globale samfunn.

Go Back   UNIX og Linux Forums > Top Forums > UNIX for Dummies Spørsmål og svar > Svar på vanlige spørsmål > Tips og Tutorials
.
google unix.com



Tips og Tutorials Nyttige artikler fra våre brukere.

Mer UNIX og Linux Forum Emner Du kan finne nyttig
Tråd Tråd startet Forum Svar Siste innlegg
Å gi "Unzip" tillatelser og "skape" filrettigheter Mike1234 HP-UX 3 03-02-2008 05:34
Unix permissions mobershaw Sun Solaris 0 01-24-2006 06:06
UNIX filrettigheter jerardfjay UNIX for Advanced & ekspertbrukere 3 03-15-2005 12:25
Unix permissions moukoko UNIX for Dummies Spørsmål og svar 2 03-11-2004 08:12

 
English Japanese Spanish French German Portuguese Italian Dutch Swedish Russian Norwegian Hungarian Hebrew Danish Bulgarian Greek Powered by Powered by Google
 
LinkBack Thread Tools Søk i denne tråden Vurdering: Thread Rating: 6 votes, 4.83 average. Visningsmoduser
  #1 (permalink)  
Old 05-28-2005
Perderabo's Avatar
Perderabo Perderabo is offline Forum Staff  
Unix Daemon
  
 

Bli Dato: Aug 2001
Beliggenhet: Ashburn, Virginia
Innlegg: 9114
Unix filrettigheter

Innledning

Jeg har sett noen Feilinformasjon om Unix filrettigheter. Jeg vil prøve å sette posten rett. Ta en titt på dette eksempelet fra noen lyd fra ls:
Code:
$ ls -ld /usr/bin /usr/bin/cat
drwxrwxr-x   3 root     bin         8704 Sep 23  2004 /usr/bin
-r-xr-xr-x   1 bin      bin         9388 Jul 16  1997 /usr/bin/cat
$
På den første linjen som "root" sier at katalogen er eid av brukeren kalt "root". Og at "bin" er den gruppen av katalogen. Du må forstå brukere og grupper, og jeg vil anta at du gjør det. Mitt mål er å forklare at "drwxrwxr-x" og "-r-XR-XR-x" ting. Dette feltet er en kombinasjon av filtypen og tilgang tillatelse. Samlet denne informasjonen kalles det fil modus. Og noen ganger er det som kalles permissions. Et godt sted å starte er ved å ta en rask titt på hvordan denne informasjonen faktisk er lagret på disk. Måten den er lagret påvirker en rekke vedtak som er gjort opp gjennom årene.

Hvordan "File Mode", er lagret.

På disken, informasjon om en fil er lagret i struktur kalt en "inode". Hver fil vil ha det selv inode. En data element i en inode kalles "modus", og det ser slik ut:
Code:
 |------file mode------|
 |                     |
 |
 |       |----full-----|
         |
 |-type| |   |--basic--|
 |     | |   |         |
 oo0 000 000 000 000 000
 ... ... ... ... ... ...
    |     |   |   |   |
    |     |   |   |   |---- rwx for other
    |     |   |   |
    |     |   |   |-------- rwx for group
    |     |   |
    |     |   |------------ rwx for user
    |     |
    |     |---------------- set uid, set gid, sticky bit
    |
    |---------------------- file type: regular (-)
                                       directory (d)
                                       character special (c)
                                       block special (b)
                                       fifo (p)
                                       symbolic link (l)
                                       socket (s)
Jeg tror at "modus" egentlig betyr bare tillatelser og at filtypen var shoved i å spare plass. Men forfatteren av ls programmet er å behandle modus som et enkelt element. Derfor filtypen er det første tegnet i tillatelse streng i "ls-l" output. Filtypen vanligvis vil være en av de sju som jeg viser ovenfor. Noen versjoner av Unix vil legge til noen flere. Den eneste andre ting å merke seg fra data oppsettet er at det ikke er rom for å legge til flere tillatelse biter.

Representerer disse tillatelsene i oktal

Den, det ls Programmet kan vise, sier "rwxrwxrwx" for tillatelser for en fil. Det er også svært vanlig å bruke en oktal for å uttrykke tillatelsene på en fil. Og som du ser over, er hvordan de er lagret. Du kan høre noen si at noen har 777 tillatelser. Dette er det samme som "rwxrwxrwx" og mye lettere å uttale. Så du trenger å vite hvordan du konverterer dem. Tre binære sifre eller biter tilsvarer en oktal siffer:

Code:
  421
  rwx
Så "lese litt er verdt 4, skrivehastigheten bit er verdt 2 og effektuere bit er verdt 1. Du bare legge disse opp å få en oktal siffer. So"-rwxrwxrwx "er 777. Og"-rwxr-x -- - "er 750. Hvis du fortsatt ikke kan se hvordan du kommer fra" rx "til 5, kanskje denne tabellen vil hjelpe:

Code:
--- = 0
--x = 1
-w- = 2
-wx = 3
r-- = 4
r-x = 5
rw- = 6
rwx = 7
Merk vi trenger 4 oktal sifre å uttrykke alle tillatelse biter. De tre første bitene er spesielle og ofte null. Og du nesten alltid lære om etterfølgende 9 biter først. Noen stopper der og aldri lærer de første tre biter. Men det er 12 tillatelse bits, ikke bare 9. Når det er sagt, la oss nå ta en titt på de etterfølgende 9 biter.

Basic Tillatelse Bits

Vi har 3 Tripler: en trippel for brukeren, en trippel for gruppen, og en trippel for andre. Noen ganger er "bruker" heter eieren. Og noen ganger "andre" kalles "verden". Jeg vil bruke "brukernavn" og "andre" fordi chmod kommandoen bruker bokstaver ug og o til å henvise til disse Tripler.

Hvilken sett Bits gjelder for deg?

Når Unix bestemmer hva du kan gjøre, ikke bruke alle 9 biter. Unix plukker første trippel som gjelder for deg. Tenk på dette:
Code:
----rwxrwx   1 joe        users           29 Mar 22 19:39 somefile
Selv om Joe eier denne filen, kan han ikke tilgang til den. (Siden joe eier filen, han kunne gi seg selv tilgang. Mer om det senere.) Også root er spesiell. root gis rwx alle kataloger og RW til alle filer. På en fil, hvis en av 3 x biter er satt, root har execute tillatelse. Denne spesielle tillatelse ofte er deaktivert på nettverket montert filsystemer.

Hva RW og x virkelig bety for en fil?

For en fil, "lese" og "skrive" er ganske intuitiv. X for "execute" betyr at kjernen kan prøve å kjøre filen. For det skal fungere, må filen en kjørbar (output fra en kompilator) eller et shell script med "#!" første linje. For en katalog ting er litt mer komplisert. Med en katalog, "skrive" tillatelse betyr at du kan opprette nye filer i katalogen eller fjerne gamle filer. Det noen overraskelser personer som du kan fjerne en fil som du ikke kan lese. Unix rm kommandoen test for det og utstede en advarsel, men du kan undertrykke at advarselen med-f. Og advarsel eller ikke, hvis du vil fjerne en uleselig fil fra en skrivbar katalog, kan du. Og RMDIR vil ikke plage å se på alle.

Hva RW og x egentlig betyr for en katalog?

En katalog er en fil også, og "lese" tillatelse betyr at du kan lese den. Men du kan ikke gjøre så mye uten x tillatelse også. Med kataloger, du må som regel både lese og effektuere tillatelsen eller ingen av delene. En katalog, at x er offisielt kalles "søk tillatelse". Du trenger x å bruke en katalog på en bane. Så hvis du prøve "cat / etc / passwd", vil du trenge x på / og / etc. Du må også x til cd inn i en katalog. Anta at du har lest, men ikke søke (x) tillatelse til en katalog. Hva kan du gjøre? Ikke mye. Du kan bruke "ls" for å vise filnavn. Even "ls-l" vil ikke fungere. Les tilgang uten å søke tillatelse er ikke veldig nyttig. Fremdeles som er bedre enn å bare skrive tillatelse en katalog ... som er helt ubrukelig. Jeg har ikke sett noen annen dokumentasjon som sier dette, så la meg gjenta det: skrive, men ikke effektuere tillatelsen en katalog gir ingenting ved all.Suppose du har søk (x) tillatelse, men ikke lese tillatelse til en katalog. Nå kan du åpne filene i katalogen hvis du vet fil navnet. Du kan cd inn i katalogen. Og det er det. Du kan ikke opprette en ny fil. Legge skrive tillatelse kan du opprette filer. Og du kan deretter slette filer hvis du vet navnet.

Symbolske lenker er spesielle

Tillatelse på en symbolsk lenke er litt spesielle også. De er helt ignorert. Mange versjoner av Unix har ingen mulighet til å endre dem.

Den setuid og Setgid Bits

Ta en kikk på dette:
Code:
$ ls -l /etc/passwd /etc/shadow /usr/bin/passwd
-r--r--r--   1 root     sys        14006 Jan 14 11:17 /etc/passwd
-r--------   1 root     sys         8281 Jan 14 11:18 /etc/shadow
-r-sr-sr-x   3 root     sys        96244 Sep  5  2001 /usr/bin/passwd
Den passwd filen er writable bare root (Husk at root er spesiell. Det kan skrive en fil som ikke har skrive-tillatelser angitt). Skyggen fil, hvor passordene er lagret, kan ikke leses av vanlige brukere. Men joe ønsker å endre passordet. Han kan gjøre det ved å kjøre / usr / bin / passwd. Innkalling de rs tillatelser. Den passwd program har suid og sgid biter sett. Dette slår X inn s's. I oktal vil det være 6555. Den passwd program eies av rot. Når joe kjører den, den kjører ikke som "Joe". I stedet, det går som det eier som er roten. Så passwd program kan endre joe passord for ham. Den sgid bit fungerer på samme måte, bortsett fra det forårsaker passwd program til å kjøre med gruppen sys istedenfor Joe's gruppe. Den suid og sgid ikke får sin egen posisjon i ls. Når suid bit er angitt, ls viser så stedet ax for eieren utfører tillatelse. Hva om suid bit er satt, men eieren execute bit av? ls viser en kapital S i saken. Den sgid bit vises på en lignende måte, bortsett fra at det virker sammen med gruppen utføre tillatelse. (Settet uid konseptet ble oppfunnet av Dennis Ritchie som han utvikler Unix.)

Utvid på tingene litt, mens joe kjører suid til root passwd program, "Joe" er den virkelige uid og "root" er effektiv uid. Den passwd program kan få begge disse id's hvis den vil. Slik passwd program vet å tillate joe å endre bare joe passord.

Klebrige Bit

Den, det Posix standarden sier at hvis klebrige bit er satt på en katalog, bare skrive tillatelse til katalogen er ikke lenger nok til å la filene som skal fjernes. Du må i tillegg eier av filen eller egen katalog. root fortsetter å være i stand til å slette en katalog uavhengig av tillatelser. Tidligere denne bit servert et annet formål. På noen OS er det fortsatt gjør. Jeg vil utdype i et vedlegg nedenfor. Klebrige bit påvirker "andre" execute bit i ls vise. Bortsett fra at den bruker t og T i stedet for s og S. For eksempel:
Code:
drwxrwxrwt   5 root       root          1024 Feb 11 20:43 /tmp
I den / tmp katalogen ovenfor, kan alle opprette nye filer. Men på grunn av den klebrige biter, en bruker kan ikke slette en brukers filer.

Begrense filrettigheter med umask

Når filene er laget programmet som skaper kan angi den opprinnelige tillatelse innstillingen. Du kan overstyre den med umask. The umask er et sett av forbyr biter. Det er en umask kommando som gjør at du kan vise og endre umask. For eksempel "umask 022" forbyr gruppen skrive og skrive på nyopprettede filer. Eller "umask 027" forbyr gruppen skrive og den forbyr andre lese, skrive, eller utføre. Du kan gjøre en "umask 0" for å la programmet gjøre hva de ønsker som det skaper programmer. Men du kan ikke gå videre. Du kan ikke tvinge et program for å slå litt på. The umask påvirker filer, kataloger navngitte datakanaler (aka fifos), og spesielle filer. Det kan påvirke symbolske lenker. Det påvirker også somes former for Inter Process Communication men det er utenfor rammen av denne artikkelen. Og tro det eller ei, heter socketer er fritatt fra umask. Dette unntaket er nødvendig ved Posix.

Endre filrettigheter med chmod

Bare eieren av en fil eller root kan endre rettigheter på en fil. Denne operasjonen er ikke påvirket i det hele tatt av umask innstillingen. Hvis du endre tillatelser for en symbolsk kobling, koblingen vil bli fulgt, og du vil endre målet fil. Det er mulig at bare root har makt til å sette en fil er klebrig bit. Som eksempel, "chmod 700 somefile" vil la eieren lese, skrive og kjøre filen, mens disallowing all tilgang til andre brukere.

Bruke Symbolsk med chmod og umask

Posix innført en ny syntaksen for chmod kommandoen. Ideen var at det nye syntaks vil erstatte bruk av en oktal konstant med chmod kommandoen. Den oktal konstant er fortsatt tillatt, og jeg tror det er kommet for å bli. Men den nye symbolske syntaks kan du endre noen biter uten å vite hva de andre er. La oss for eksempel si at jeg vil lage en fil utilgjengelige for andre, men jeg forstår ikke hva du skal endre acess for brukeren eller gruppen. Jeg trenger å gjøre:
ls-l fil
Se på filen og finne ut av gjeldende innstillinger.
chmod 750 fil
Jeg måtte finne ut at de to første sifrene er strømninger 7 og 5 før jeg kunne gjøre mitt chmod kommandoen. Med den nye syntaks, kan jeg bare gjøre:
chmod o \u003d fil
å slå av den siste 3 biter. Som et annet eksempel, "chmod u + x fil" tillater brukeren å kjøre filen. På den andre siden har disse to kommandoene tilsvarende:
chmod 750 fil
chmod u \u003d rwx, g \u003d rx, o \u003d fil
Jeg foretrekker den første syntaks.

Symbolske modus kan være en kommadelt liste over spesifikasjonene. Hver spesifikasjonen har tre komponenter: <who> <operation> <bitlist>
Code:
The who part can be:
u  (user)
g  (group)
o  (other)
a  (all)
   (whatever is allowed by umask (subset of all))

The operator can be  = or - or +
= (set bits to bitlist)
- (subtract bitlist from current bit
+ (add bitllist to current bits)

The bitlist can be one of the following letters:
r (read permission)
w (write permission)
x (execute permision)
X (conditional execute permision)
u (current permissions for user)
g (current permissions for group)
o (current permissions for others)
s (set uid or set gid)
t (sticky bit)
X er det samme som x hvis filen er en nondirectory og har i dag ingen x biter sett. S (sette uid eller satt GIDen) bare kan angis for brukeren eller gruppen tillatelsene. T bare kan angis for brukertillatelser. Noen få eksempler med hjelp. Fremfor vi så / usr / bin / passwd var 6555 (-r-sr-sr-x i ls). Her er noen måter som kan oppnås:
chmod 6555 / 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 det er mange andre måter å gjøre dette.

For det meste chmod er uimottakelig til umask i at det biter de ønsker å stille ikke blir endret av umask. Men under en tilstand, det chmod kommandoen vil undersøke gjeldende innstilling av umask til å avgjøre hvilke biter det vil angi. Dette skjer når du forlater "som"-feltet stå tomt. Slik:
chmod \u003d w somefile
Forskjellen mellom "a \u003d w" og "\u003d w" er subtile. Her er et eksempel som kan hjelpe. Mange programmer prøver å opprette filen med 666 (-RW-RW-RW-) rettigheter. Men dette blir endret av umask. Anta at du vil angi en fil til 666, men endret av gjeldende umask. Vi kunne slå av alle biter, og deretter slå på lese og skrive biter som er tillatt etter gjeldende umask:

chmod a \u003d, \u003d RW somefile

Og snakke med umask, kan du bruke symbolske argumentene med umask-kommandoen også. Uansett, imidlertid, Posix, I sin visdom, besluttet at i denne hendelsen logikk ville bli reversert. Så hvis bruke umask med oktal Argumentet du angir biter å være forbudt. Men hvis du bruker umask med en symbolsk argument, kan du angi en bit til å tillate. Så disse er likeverdige:
umask 022
umask u \u003d rwx, go \u003d rx

Sammendrag

På dette punktet du har nok informasjon til det meste forstår de 12 tillatelse biter. Det er flere helt spesielle tilfeller at jeg har oversett eller glossed over. I egne innlegg nedenfor vil jeg rette på dette. Informasjonen i dette første innlegget er ganske mye universell. En Posix kompatibelt OS må støtte denne ting. Som dekker nesten alle versjonene av Unix utgitt i de siste 10 årene. Følgende artikler drøfte funksjoner som kanskje ikke universell.
 

Hugseliste

Tags
chmod, filrettigheter, linux-kommandoer, klebrig bit, suid, umask

Thread Tools Søk i denne tråden
Søk i denne tråden:

Avansert søk
Visningsmoduser Ranger denne tråden
Ranger denne tråden:

Innleggsaktivitet Regler
Du kanskje ikke poste nye tråder
Du kanskje ikke poste svar
Du kanskje ikke post vedlegg
Du kanskje ikke redigere innleggene dine

BB-kode er
Smilefjes er
[IMG] koden
HTML-koden Av
Pingbacks er
Refbacks er




Alle klokkeslett er GMT -4. Nå er klokken 07:23.


Powered by: vBulletin, Copyright © 2000 - 2006, Jelsoft Enterprises Limited. Language Translations Powered by .
vBCredits v1.4 Copyright © 2007 - 2008, PixelFX Studios
UNIX og Linux Forums Content Copyright © 1993-2009. All Rights Reserved.Ad Management by RedTyger

Content Relevant nettadresser av vBSEO 3.2.0