Ero sivun ”Kansion yhteiskäyttö ryhmässä” versioiden välillä
LP (keskustelu | muokkaukset) (korjataan esimerkkikomentojen tietoturva-aukko) |
Jem (keskustelu | muokkaukset) (Linkki korjattu.) |
||
Rivi 72: | Rivi 72: | ||
=== ACL eli pääsynvalvontalistat === | === ACL eli pääsynvalvontalistat === | ||
Linuxissa voi ottaa käyttöön [[ACL]]-toiminnon, jonka avulla tiedosto-oikeuksien hallintaa voi tehdä huomattavasti yksityiskohtaisemmin. ACL-toiminto vaatii kuitenkin jonkin verran opettelua ja konfigurointia. | Linuxissa voi ottaa käyttöön [[Tiedostojärjestelmän pääsylistat (ACL)|ACL]]-toiminnon, jonka avulla tiedosto-oikeuksien hallintaa voi tehdä huomattavasti yksityiskohtaisemmin. ACL-toiminto vaatii kuitenkin jonkin verran opettelua ja konfigurointia. | ||
== Käyttö Windows-järjestelmien kautta == | == Käyttö Windows-järjestelmien kautta == |
Versio 16. syyskuuta 2011 kello 14.52
Joskus on tarvetta sille, että tietokoneella on hakemisto, johon usealla käyttäjällä on sekä luku- että kirjoitusoikeudet pysyvästi siten, että myös kaikissa uusissa ja muokatuissa tiedostoissa säilyy ryhmän sisäinen luku- ja kirjoitusoikeus.
Tällainen tilanne on esimerkiksi:
- palvelimella, jossa useampi henkilö tekee yhdessä jotakin projektia tietyssä hakemistossa ja halutaan, että ryhmän sisäinen luku- ja kirjoitusoikeus säilyy myös uusissa ja muokatuissa tiedostoissa.
- kotona, jos vaikkapa jokaisella perheenjäsenellä on oma käyttäjätunnus, mutta halutaan silti pitää tietyssä hakemistossa yhteinen multimedia-arkisto, joihin kaikilla on luku- ja kirjoitusoikeus.
Perinteinen järjestely
Perinteinen asetelma on, että tietokoneen varsinaiset käyttäjät kuuluvat yhteen ryhmään ("users") tai että usein yhteistyötä tekevät kuuluvat samaan hallinnollisen jaon mukaiseen ryhmään ("asiakaspalvelu"). Tässä asetelmassa yleensä käytetään umask-arvoa 027, jolloin ryhmällä on lukuoikeudet, muttei kirjoitusoikeuksia, uusiin tiedostoihin.
Jotta väljä umask ei haittaisi, henkilökohtaiset tiedostot laitetaan hakemistoihin, joiden käyttöoikeudet on käsin rajattu tai oikeudet rajoitetaan tiedostokohtaisesti. Kotihakemiston lukuoikeus voi myös olla hyvä poistaa:
chmod go= ~/salainen/ chmod go= ~/.netrc chmod go=x ~/.
Uusi ryhmä ja sgid
Jos yhteistyötä tekevät eivät ennestään kuulu samaan ryhmään, perustetaan uusi ryhmä, johon yhteistyötä tekevät liitetään. Koska tämä ryhmä ei ole käyttäjien ensisijainen ryhmä, uudet tiedostot pitää joko erikseen siirtää kyseisen ryhmän omistukseen tai yhteiseen hakemistoon on asetettava sgid-bitti ("Set Group IDentity"), jolloin uudet tiedostot perivät hakemiston ryhmän ja alihakemistot myös sgid-bitin.
mkdir /export/leffat chgrp perhe /export/leffat chmod ug=rwx,o= /export/leffat chmod g+s /export/leffat
Nyt tähän hakemistoon ei ole pääsyä kuin ryhmällä perhe, mutta perheen jäsenet voivat luoda, muokata ja poistaa tiedostoja hakemistosta. Uusi tiedosto tai alihakemisto saa omistajakseen sen luojan ja ryhmäkseen ryhmän perhe.
Huom! Tiedostojen g+s on eri asia kuin hakemistojen g+s. Jos tiedostolle asettaa g+s:n, se tarkoittaa sitä, että kun tiedosto suoritetaan, se suoritetaan tiedoston ryhmän oikeuksin (jos kyseessä siis on tietokoneohjelma). g+s pitääkin asettaa nimenomaan hakemistoille.
Toimivuus
Ryhmällä ei ole oikeuksia muuta kuin mitä tiedoston luoja sille antaa (käyttäjän umask määrää oletusoikeudet). Jos käyttäjällä on umask 027 tai vastaava, joka antaa ryhmälle lukuoikeudet, kuka tahansa ryhmästä voi kopioida tiedoston ja tallettaa sen uudestaan haluamillaan oikeuksilla, mahdollisesti muokkauksen jälkeen. Kirjoitusoikeuksien puuttuminen ei siis käytännössä estä muita muokkaamasta tiedostoa.
Ongelmia tulee silloin, kun jollakin käyttäjällä on tiukempi umask, joka ei automaattisesti anna muille lukuoikeuksia. Vastaava tilanne syntyy, kun tiedosto siirretään muualta, jolloin ryhmä ja oikeudet pysyvät entisellään. Tällöin käyttäjän on aina muistettava asettaa oikeudet sallivammiksi tai root (mahdollisesti ajastetun työn muodossa) joutuu korjaamaan oikeuksia.
Liian väljä umask ei haittaa tässä yhteydessä, koska mahdollisesti salassapidettävät tiedostot pysyvät salassa hakemiston oikeuksien turvin, kuhan ryhmään kuulumattomilla ei ole oikeuksia hakemistoon. Salassapidettäviä ja julkisia tiedostoja ei kannata pitää samassa hakemistossa.
Rajoitettu kirjoitusoikeus
Jos yhteisessä hakemistossa pidetään tiedostoja, joita ei haluta muiden tuhoavan, hakemistolle voi asettaa t-bitin. Tällöin kirjoitusoikeus hakemistoon ei riitä poistamaan muiden tiedostoja.
chmod +t /export/leffat
Oikeuksien ja omistajuuden korjaaminen
Koska käyttäjä voi asettaa tiedostoille vääriä oikeuksia ja omistajuuksia, oikeuksia voi joutua korjaamaan. Tällainen automaattinen "korjaus" edellyttää, että käyttäjät eivät odota voivansa hallita tiedostojen oikeuksia kyseisessä hakemistossa.
Setgidin käyttöönottaminen näppärästi
1. Anna hakemisto ryhmän omistukseen:
sudo chgrp -R tiimi /export/tiimihakemisto
2. Aseta hakemistoille oikeudet JA setgid-bitti
sudo find /export/tiimihakemisto -type d -exec chmod g+rwxs {} \;
3. Aseta tiedostoille muokkausoikeudet
sudo find /export/tiimihakemisto -type f -exec chmod g+rw {} \;
Tässä muodossa komennot sisältävät ison tietoturva-aukon:
$ ls -l ~joku/salainen.txt -rw------- 1 joku jotkut 43245 9.3.2011 salainen.txt $ ln ~joku/salainen.txt /export/tiimihakemisto
Ja komentosarjan jälkeen tiimin jäsenillä olisi täydet oikeudet salaiseen tiedostoon (katso kova linkki). Parempi versio:
#!/bin/sh find /export/tiimihakemisto \( -type d -o -type f -links 1 \) \! -group tiimi -execdir /bin/chgrp tiimi '{}' \; find /export/tiimihakemisto -type d \! -perm -2070 -execdir /bin/chmod g+rwxs '{}' \; find /export/tiimihakemisto -type f -links 1 \! -perm -060 -execdir /bin/chmod g+rw '{}' \;
Tiedostojen osalta varmistetaan testillä "-links 1", että tiedosto esiintyy vain tässä hakemistossa (jolloin ylläkuvattu hyökkäys estetään; hakemistot toimivat eri tavalla). Omistaja ja oikeudet muutetaan vain jos on muutostarvetta (jolloin ctime ei muutu turhaan). "-execdir" suoritetaan kyseisessä hakemistossa, millä vaikeutetaan joitakin hyökkäyksiä (race condition), mutta tämän takia komennoille on annettava koko polku, siltä varalta että suorittajalla on "." oletuspolussaan.
Ajastettu oikeuksien korjaus (cron)
Hakemistorakenne kannattaa joissakin tapauksissa käydä läpi säännöllisesti virheellisyyksien korjaamiseksi. Tämä hoituu koneen käytöstä riippuen ohjelmilla cron ja anacron.
Cronin ajettavaksi voi laittaa ylläkuvatun skriptin kerran tunnissa tai vuorokaudessa. Huono puoli on se, että ratkaisu kuluttaa turhaan resursseja silloin kun mikään ei ole muuttunut eivätkä muutokset tapahdu reaaliaikaisesti.
Taustaprosessi
Ongelmista pääsisi taustaprosessilla, jolle ydin kertoo muutoksista, jolloin virheet voitaisiin korjata sitä mukaa kuin ne syntyvät, eikä hakemistoja tarvitsisi käydä läpi turhaan. Tähän ei vielä ole vakiintunutta ratkaisua, vaan tarvitseva joutuu itse koodaamaan tai etsimään sopivaa ohjelmaa.
ACL eli pääsynvalvontalistat
Linuxissa voi ottaa käyttöön ACL-toiminnon, jonka avulla tiedosto-oikeuksien hallintaa voi tehdä huomattavasti yksityiskohtaisemmin. ACL-toiminto vaatii kuitenkin jonkin verran opettelua ja konfigurointia.
Käyttö Windows-järjestelmien kautta
Samba
Sambaan voi melko tarkkaan määrätä uusien tiedostojen ja hakemistojen oikeudet ja omistajuudet. Käyttämällä jaettua hakemistoa samban kautta ei tällöin pääse muuttamaan oikeuksia vääriksi. Hakemistoa ei tarvitse jakaa verkkoon, vaan sitä voi käyttää localhostin kautta.
Osio Windowsin tiedostojärjestelmällä
Esimerkiksi sellaisessa tilanteessa, jossa perheen kaikki multimediatiedostot ovat yhdellä osiolla ja sitä halutaan käyttää myös Windowsista, näppärä ratkaisu on laittaa osion tiedostojärjestelmäksi NTFS ja sitten liittää se Linuxin sopivalla umask- ja ryhmätiedoilla, jolloin kaikki osion tiedostot ovat varmasti samoilla omistus- ja käyttöoikeuksilla.
Esimerkkirivi /etc/fstab-tiedostosta:
/dev/hda1 /mnt/windows ntfs defaults,umask=002,gid=1005 0 0