ITKACL-Implementasjon

ACL-sjekking

Kanskje det mest sentrale punktet for hvordan ACLer er implementert er hvilken rekkefølge ting sjekkes i; det er viktig at man forstår dette så man ikke setter opp gale tilganger. (Merk at webinterfacet vil sortere dette riktig for deg, så hvis man sjekker fra toppen og nedover vil man få riktig resultat for objektet man ser på.)

ACLer sjekkes etter følgende prioritet:

ACLer lenger ned i treet overstyrer ACLer høyere opp i treet.
Brukerrettigheter overstyrer grupperettigheter.
Tilgangsnekt overstyrer tilgang.

For å gjøre det helt klart: Alle tilganger under "/web/amsit" vil overstyre alle tilganger under "/web", så dersom en bruker er satt opp til å ha tilgang på "/web" men er blitt nektet tilgang under "/web/amsit" (enten som bruker eller i kraft av å være medlem i en gruppe som blir nektet tilgang) vil vedkommende nektes tilgang til "/web/amsit".

For å gjennomføre denne policyen traverseres treet naturlig nok fra roten og ned til man kommer til det ønskede objektet – en boolsk variabel "curr_status" (som spesifiserer om brukeren får tilgang eller ikke) starter på verdien false og overskrives hver gang man kommer til et objekt som matcher brukeren eller en gruppe vedkommende er medlem av, naturlig nok sortert i omvendt prioritetsrekkefølge (ettersom tilganger som sjekkes seinere overstyrer tilganger som sjekkes tidligere, og dermed blir mer viktige).

Merk at den spesielle (case-sensitive) gruppen "<everyone>" matcher alle brukere uansett. Alle andre brukere og grupper man refererer til i ACLer burde eksistere, ellers er oppførselen til systemet noe udefinert (men det burde nok gå greit i praksis).

Lagring

Alle ACLer og objekter er lagret i en PostgreSQL-database på cirkus, kalt "itkacl". Brukeren "itkacl-web" har full tilgang til alle tabellene, og brukeren "itkacl" har lesetilgang. Klienter spør ikke mot databasen, men mot DNS (se ITKACL2).

Det eksisterer to tabeller, "objects" og "aclentries". "objects" definerer (naturlig nok) objekttreet, med en unik ID, et navn (dvs. path-entry, f.eks. "sg"), en beskrivelse (f.eks. "Serveringsgjengen") og nodens foreldrenode (dvs. IDen til foreldrenoden, eller NULL om objektet er et rotobjekt). Det kan eksistere flere rotobjekter, men webinterfacet kan ikke lage nye per i dag. (Se ITKACLIntro for noen generelle hint om hvordan strukturen og ACLene burde bygges opp.)

"aclentries" definerer naturlig nok ACL-elementer på et objekt – det er en enkel (usortert, sorteringen gjøres som nevnt under "ACL-sjekking over") liste som definerer hvilket objekt elementet gjelder, hva slags entitet det gjelder (bruker/gruppe), hvilken entitet (dvs. bruker- eller gruppenavn) og om entiteten skal ha tilgang (grant) eller ikke (deny). Generelt er nok databasen rimelig enkel og lettforståelig for de fleste, minus at det å implementere et tre i SQL aldri kan bli enormt pent.

Lenker: Start, itkacl, itkaclintro