Det största problemet för min del med ACL var väl att förstå hur det funkar. Bäst hjälp fick jag genom att skriva "man /usr/bin/chmod" i terminalen och läsa igenom vad som står där. Man sitter och googlar en massa, men glömmer ofta bort att kolla man-filen... Ett problem i sammanhanget är att som default i opensolaris används GNU chmod, vilket inte kan användas för ACL-modifieringar så därför skrev jag hela sökvägen till solaris chmod. Samma sak gäller ls.
Problemet: Filer som skapas från Windows på en share utdelad med CIFS får "konstiga rättigheter". Som default med ls -al så ser det ut som filerna har 000 rättigheter, men ändå så har man åtkomst till filerna både lokalt och via smb. Jag ville veta varför. Dessutom är det risk att man får problem med NFS version 3 (opensolaris stödjer även NFS version 4 som stödjer ACL till skillnad från version 3) om "unixrättigheterna" inte är som man vill.
Orsak: Rättigheterna styrs av ZFS NFSv4 style ACL, alltså access kontroll listor. CIFS servern mappar dessa mot "NTFS-rättigheter" i windows när en windowsdator ansluter sig. Dessa rättigheter blir som default ställda från Windowsdatorn som ansluter till en CIFS share när filer och mappar skapas. Man tappar alltså lätt kontrollen för filåtkomsträttigheterna när windowsdatorerna härjar fritt på en CIFS share. Kör man en windowsdomän kanske man har kontrollen därifrån (via en windows domänserver kanske eller active directory möjligen, jag kan inte sådant) men jag kör workgroup mode och då tappar man helt kontrollen tycker jag.
Lösning: Ställ in rättigheterna på den utdelade mappen med ACL så att nya skapade mappar och filer ärver dessa rättigheter från rotmappen i aktuell share istället för att få dem ställda från Windows. Men det är småkrångligt att ställa in dessa rättigheter så att resultatet blir som man vill så man bör läsa på en del och testa sig fram.
"Standardlösningen" när något är krångligt med rättigheter är ju att ge fullständiga rättigheter till sin share åt alla och sen kan alla göra vad de vill med filer och mappar. Själv ville jag ha mera kontroll.
Då jag använder "workgroup mode" för CIFS-servern så funkar det som så att för att kunna logga in på en CIFS-share så måste man ange användarnamn och lösenord för en användare på opensolaris-datorn. Så rättigheterna mappas alltså mot de lokala användarna i opensolaris så man får skapa användare som motsvarar de "fjärranvändare" som ska ansluta sig (helst med samma användarnamn och lösen som i klientdatorerna så blir det lättare för användarna).
Mitt mål var att ha en gemensam lagring som alla användare kom åt. Detta har jag löst genom att låta alla opensolarisanvändare som ska komma åt denna share tillhöra gruppen users som jag skapat för ändamålet (har satt den som default grupp för dessa användarre). Sedan så har jag satt gruppen users (samt mig själv) som ägare till den utdelade mappen. Med hjälp av /usr/bin/chmod så kan man sedan modifiera rättigheterna inklusive ACL så att det blir som man vill.
ACL har många fler grejer man kan ställa in än bara läs, skriv, execute som man normalt gör med chmod. Man kan t.ex. ange om man har rätt att ta bort filer, rättighet att ändra ACL, rättighet att ge bort filer till andra ägare o.s.v. Förutom owner, group och everyone så kan man ge andra användare eller grupper rättigheter också. Man kan även ställa in hur rättigheter ska ärvas till nyskapade undermappar och filer.
Själv har jag utnyttjat detta och skapat en användare smbadmin som har full åtkomst till allas filer och mappar. Ägare till filerna och mapparna har jag gett full åtkomst till egna filer (förutom exekveringsrättigheter på filer som nekas alla samt möjlighet att ändra ACL som jag också nekar alla). Andras filer tillhörande samma grupp har jag gett skriv och läsmöjligheter, men man får inte radera andras filer och mappar (vill undvika att någon annan tar bort något man själv lagt upp av misstag). Med hjälp av everyone@ har jag gett övriga som inte anges på annat sätt endast läsrättigheter och även möjlighet att bläddra runt i mappar.
Tack vare ACL kunde jag ställa in detta som jag ville ha det. Det hade inte gått med bara vanliga unix-rättigheter tror jag.
Som det är nu är det bara en sak som krånglar för mig. Det är när man från en windowsdator flyttar upp en fil från en undermapp till roten på den share man delat ut så ställs rättigheterna till user:ägarnamn och group:gruppnamn, alltså det blir user:ronny istället för owner@ och gruop:users istället för group@ och detta resulterar till att jag får 444 rättigheter istället för 664 rättigheter på denna fil (blir väl så eftersom det blir begränsat till en viss ägare och en viss grupp istället för vilken ägare som helst och vilken grupp som helst som råkar äga filen/mappen för tillfället). Om jag däremot kopierar filen (istället för att flytta) upp till roten på denna share så behålls rättigheterna från originalfilen och sedan kan jag ta bort originalfilen och rättigheterna behålls ändå på kopian. Dessutom om jag går ner djupare i filträdet, alltså flyttar upp en fil till en mapp ovanför aktuell mapp men inte ända upp till rotmappen då blir rättigheterna på owner@ och group@ som jag vill ha det. Jag kan inte se någon skillnad på ACL hos undermapparna och rotmappen så jag tror att detta beteende är en bugg faktiskt. Förresten ska man rapportera denna bugg och i så fall hur och var gör man detta?
Buggen får till följd att om jag är en annan användare än den som äger rotmappen i aktuell share (men ändå tillhör gruppen som äger rotmappen) flyttar upp en fil till roten på denna share så förlorar användaren rättigheten att ta bort filen eftersom ägaren byts till den användare som äger rotmappen (jag hade ju ställt in att man inte har rättighet att ta bort andras filer). Man förlorar alltså ägarskapet på den fil som man själv ägde innan man flyttade upp den till rotmappen (såvida man inte själv också är ägare till rotmappen). Är man själv ägare till både rotmappen och den ursprungliga filen märker man inget flörutom att rättigheterna ser ut att vara 444 istället för 664. Detta kan kanske ge problem i andra sammanhang såsom NFSv3 t.ex om man gör något som inte stödjer ACL i ZFS.
Därför har jag lagt till användaren smbadmin som alltså har rätt att ta bort även andras filer så att man med hjälp av denna kan städa upp efter andra användare via smb så man slipper logga in som root. Detta gick ju bra att göra genom att ge dessa rättigheterna till user:smbadmin med ACL.
Här är några länkar:
http://gibbs.acu.edu/2008/07/20/my-cifs-on-zfs-acl/
http://vmsysadmin.wordpress.com/2009/01/18/using-zfs-acls-to-...
http://www.aspdeveloper.net/tiki-index.php?page=SolarisCIFSPe...
http://opensolaris.org/jive/thread.jspa?messageID=266839
Jag vet inte om detta är något du måste göra saddam. Beror väl på om du behöver den extra kontrollen på filrättigheter som man får med hjälp av ACL. Är du ensam användare av dina filer så behövs det kanske inte (du kan ju ge fullständiga rättigheter och strunta i detaljerna) men annars kan det vara intressant att lära sig tycker jag. Själv upplevde jag det som ett problem då jag tappade kontrollen över vad som händer när man kör som filserver med CIFS, men problemet är ju då mest att windows härjar runt med rättigheterna om man inte gör något åt det.
Jag ser ändå positivt på detta trots att det till en början orsakade mycket huvudbry. Tack vare krånglet har jag lärt mig en del om hur ACL funkar och hur man kan använda det. Jag ska senare när jag får åtkomst till min dator posta kommandoraden jag använde för att ställa rättigheterna. Den kan kanske se lite avskräckande ut...
Nu blev det inte kort skrivet, men det är inte lätt att förklara det kort tycker jag.
EDIT: Jag kom just på en eventuell möjlig "workaround" på mitt kvarvarande problem. Jag kan kanske ställa in rättigheterna med hjälp av ACL så att det blir förbjudet för användarna att skapa filer i rotmappen på min share? Då bör det inte gå att flytta filer dit heller. Alltså bara tillåta skapande av mappar i roten och sedan inuti dessa mappar får man skapa filer och undermappar som man vill. Det skulle passa bra också för jag gillar inte när det ligger filer och skräpar i rotmappen, jag vill ha allting kategoriserat. Jag ska undersöka saken...
