next up previous contents
Nästa: 7.4 Montering Upp: 7. Mer om UNIX Förra: 7.2 Länkar

7.3 Filskyddskoder

Ett alternativt sätt att ange filskyddskoder är att använda siffror. Det fungerar på så sätt att läsrättigheten är värd fyra poäng, skrivrättigheten två poäng och rätten att exekvera en poäng. Genom att lägga samman poängtalen får man en siffra som kan representera skyddskoden. Till exempel motsvarar r-x siffran 4+1=5, r-- motsvarar 4 och --- motsvarar 0.$ chmod 764 bellman
$ ls -l bellman
-rwxrw-r--   1 göran    göran         372 feb  1 16:48 bellman*
$
Den första siffran i talet 764 gäller ägarens rättigheter, den andra gruppens och den tredje de övrigas.

 Det återstår att berätta om en viktig sak i samband med rättigheter. För att ta ett exempel, filen /etc/shadow innehåller alla användares lösenord (om än i krypterad form). Bara systemadministratören har rätt att läsa och ändra den filen. Men när jag byter lösenord måste ju den filen med nödvändighet ändras. Hur går det till? Svaret får vi genom att studera filskyddskoden för passwd. Vi lokaliserar var den fil som innehåller programmet passwd finns med hjälp av kommandot which, och läser sedan av dess skyddskod:$ which passwd
/usr/bin/passwd
$ ls -l /usr/bin/passwd
-rwsr-xr-x   1 root     root        33288 apr 19 10:20 /usr/bin/passwd*
$
Det intressanta här är tecknet s i skyddskoden för passwd. När ett program exekveras, ges det vanligtvis samma befogenheter som den som startade programmet har. Om tex användaren eva kör Emacs, så får denna Emacs-process bara ändra de filer som eva får ändra. Men om det står s i stället för x i skyddskoden för ägaren till en viss fil, så betyder det att när filen körs som ett program, så ges programmet samma rättigheter som filens ägare har. Bokstaven ''s'' står här för ''sätt användaridentitet - setuid''. När programmet passwd körs, så har det alltså samma rättigheter som root, vilket betyder att det får göra nästan vad som helst. (Minsta lilla fel i programmet passwd skulle därför vara ödesdigert. En av de främsta orsakerna till säkerhetsproblem i UNIX-system är när det finns brister i program som har s-biten satt.) På motsvarande sätt kan ett program ha en s-bit i skyddskoden för grupp. Då står ''s'' för ''sätt gruppidentitet - setgid'', och processen tilldelas de befogenheter som den grupp programfilen är associerad med har.

Förutom setuid och setgid finns en tredje specialrättighet som kan tilldelas filer och kataloger, nämligen fastbiten (''sticky bit''). Egentligen är den en kvarleva från UNIX barndom. Om en katalog har sin fastbit satt, så får ingen användare (med undantag för katalogens ägare) radera någon annan användares filer i den katalogen, vilket de vanligtvis får ifall de har skrivrättighet till katalogen. Betrakta till exempel katalogen /tmp:$ ls -ld /tmp
drwxrwxrwt   3 root     root         1024 mar  9 11:25 /tmp/
$
Vi ser att fastbiten är satt eftersom ls skriver bokstaven t sist i skyddskoden. I och med att ''övriga'' har skrivrättighet till /tmp kan jag skapa och radera filer där, men jag kan inte ändra i någon annans filer eftersom fastbiten är satt.

För att sätta fastbiten använder man chmod med argumentet o+t. Setuid sätts med argumentet u+s, setgid med g+s. Specialrättigheter kan också sättas med en siffra. Då är setuid värt 4 poäng, setgid 2 poäng och fastbiten 1 poäng. Poängsumman sätts framför de tre siffror som gäller de vanliga rättigheterna:$ chmod 5764 bellman
$ ls -l bellman
-rwsrw-r-T   1 göran    göran         372 feb  1 16:48 bellman*
$
Siffran 5 är 4+1, vilket betyder att setuid och fastbiten sätts på. Därför står det nu ''s'' och ''T'' i filskyddskoden. Att ls skriver ett stort T beror på att x-biten för ''övriga'' inte är satt. Likaså skrivs stora S när setuid (eller setgid) är satt medan x-biten för ägaren (gruppen) inte är satt. Låt oss återställa skyddskoden för bellman till ett förnuftigt värde:$ chmod 664 bellman
$ ls -l bellman
-rw-rw-r--   1 göran    göran         372 feb  1 16:48 bellman
$

Hur avgörs det vilken skyddskod nya filer får? Svaret på denna fråga får vi av kommandot umask.$ umask
002
$
Värdet som skrivs ut av umask talar om vilka rättigheter som ska tas bort. Den nuvarande inställningen innebär att skrivrättigheten tas bort för ''övriga''. $ mkdir ny.katalog
$ ls -ld ny.katalog
drwxrwxr-x   2 göran    göran        1024 mar  9 13:03 ny.katalog/
$
Som synes är alla rättigheter satta utom skrivrättigheten för ''övriga''. Låt oss ändra värdet så att skrivrättigheten tas bort för gruppen medan alla rättigheter tas bort för ''övriga'':$ umask 027
$ cp bellman ny.fil
$ ls -l ny.fil
-rw-r-----   1 göran    göran         372 mar  9 13:06 ny.fil
$ rm -r ny.*
$
I rättigheterna för ny.fil saknas, förutom de rättigheter som vi ville ta bort, även alla rättigheter att exekvera. Skälet till detta är att nya filer inte automatiskt får exekveringsrättigheter eftersom det inte är säkert att de faktiskt är program som kan exekveras.


 
Tabell 7.1: De olika filtyperna.
 
Tecken Typ av fil
- Vanlig fil
d Katalog
l Symbolisk länk
b Blockspecialfil
c Teckenspecialfil
p FIFO
s Socket

Det första tecknet i den filskyddskod som ls skriver ut, anger vilket slags fil det rör sig om. En förteckning över de olika filtyperna ges i tabell 7.1. De tre första typerna är vi redan bekanta med. De övriga fyra typerna används för olika specialfiler.

Under UNIX kommunicerar man med hårdvaruenheter via en specialfil i katalogen /dev. Ett exempel på detta är filen /dev/fd0.$ ls -l /dev/fd0
brw-rw----   1 root     floppy     2,   0 maj 28 02:49 fd0
$
Tecknet b i som skrivs ut före filskyddskoden anger att det rör sig om en så kallad blockspecialfil. Den första serieporten motsvaras av filen /dev/ttyS0.$ ls -l /dev/ttyS0
crw-rw----   1 uucp     dialout    4,  64 okt 12 20:38 /dev/ttyS0
$
Tecknet c innebär att /dev/ttyS0 är en så kallad teckenspecialfil. Specialfiler av typen FIFO (''först in, först ut'') används för rörledningar. Ett exempel ges av filen /dev/xconsole:$ ls -l /dev/xconsole
prw-r--r--   1 root     root          735 mar  9 12:28 /dev/xconsole
$
Den återstående filtypen är ''socket'', som används i nätverkskommunikation. Som exempel tar vi filen /dev/log:$ ls -l /dev/log
srw-rw-rw-   1 root     root            0 mar  6 13:22 /dev/log=
$


next up previous contents
Nästa: 7.4 Montering Upp: 7. Mer om UNIX Förra: 7.2 Länkar
Goran Andersson
1999-03-08