Innhold
1 Bakgrunn
Group identifier (GID) er en int som identifiserer gruppa i et posix-system. En vanlig cerebrum-gruppe får tildelt GID første gangen gruppa utsettes for en posix_promote. Gruppa får da også en extention: PosixGroup. Alle konti på et posixsystem har en personlig filgruppe. Denne filgruppa har en GID.
Tilganskontroll på posixsystemet utføres nettopp ved GIDs. Dersom en gruppe får feil GID får den også feil tilgang på posixsystemet. Dette kan særlig forekomme i forbindelse ved gjenoppretting av slettede grupper.
1.1 Problem: Hvordan sikrer man at gids ikke blir gjenbrukt?
I dag forhindrer vi gjenbruk av GIDs ved gjenoppretting ved å unngå å slette posixgrupper. Scriptet remove_expired_groups.py vil i dag forsøke[#] å tømme utgåtte posixgrupper for medlemmer. Dette er svært lite elegant og medfører at haugevis av utgåtte grupper blir hengende igjen.
Det garanterer imidlertid at en gruppe vil ha samme GID ved gjenoppretting, for posix_demote fjerner ikke original GID, den bare tilser at flagget PosixGroup forsvinner. Problemene melder seg når en posixgruppe skal slettes fullstendig.
1.1.1 En liten innvending
Hva med ei gruppe som først degraderes, og så går ut på dato? Den har ikke PosixGroup-extension, og skal således slettes på vanlig vis, men den har vært en posixgruppe - og GIDen skal potensielt kunne bli gjenbrukt med alt det medfører. Tror jeg.
1.2 Tiltak
Ett tiltak som kan utføres for å avhjelpe er å opprette en egen tabell må GID markeres som tainted, og alle nye forfremmelser må sjekke om GID har vært brukt før. Dette gjøres ikke i dag; vi har bare en enkel counter. Dette er utiltrekkelig siden diskontinuitet ved gjenopprettelser o.l. kan forkludre.
Det er ingenting som direkte hindrer oss i å - opprette tabellen - legge inn alle eksisterende (også utgåtte!) GIDs i denne - sjekke tabellen ved alle kall til posix_prmote.
Det enkleste ville dermed være å tildele en GID ved opprettelse av alle Cerebrum-grupper i tilfelle de en gang skulle forfremmes til posixgrupper.
De eneste relevante innvendingene ville i så fall være at man kan gå tom for GIDs.
1.2.1 Antall tilgjengelige GIDs
Det er tre nivåer å være klar over:
- Signed 16-bit, litt over 32 tusen. Dette må man forholde seg til på antikke systemer, Trond Hasle Amundsen har bekreftet at vi ikke har slike systemer ved UiO som Cerebrum må forholde seg til. Våre samarbeidspartnere har også bekreftet at deres systemer er fri for slike. Men: Skulle det mot formodning dukke opp gespenster er dette verdt å ha i mente.
- Unsigned 32-bit. Omlag 4.3 milliarder. Dette er hva som brukes ved UiO i dag. Vi har i dag brukt langt under en million, så dette er mye mer enn vi noensinne vil kverne oss gjennom. Det er imidlertid ikke en uuttømmelig mengde, så det er ikke teknisk umulig å gå fri - dersom vi setter nye verdier på alle grupper ti tusen ganger hver natt eller noe annet idiotisk.
- Signed 64-bit, (bigint). Dette er formated GIDs lagres i databasen på. Dette gir oss 2^63-1 positive verdier, eller rett under 10^19. Dette er emer enn vi vil klare å bruke opp, selv med moderat feilskrevne batchjobber.
1.3 Andre ting som også må fikses
Det er ikke nok å holde styr på brukte GIDs, man må også holde orden på UIDs. Dette er ekvivalenten for PosixUser. Det er en krysskobling mellom posixgrupper og posixbrukere, og dette koker ned til Default File Group (DFG).
2 Hvorfor det ikke fikses
Dermed er det ikke nok å opprette en enkel tabell; vi må ha minst to. Hans Kristian har bestemt at utviklingskostnaden blir for stor, og posixfunksjonaliteten lever enn så lenge videre i uendret forfatning.
| [1] | Brukere som har den utgåtte posixgruppa som sin DFG kan ikke fjernes fra den. |