Wäre es nicht geschickter, man würde für das EX3 Filesystem ein neues Feature einführen, das es ermöglicht, 2 oder mehrere Gruppen eine Datei zuzuweisen?
Also, das man pro Datei, z.b. 2 Gruppen verwenden kann. Dann wäre das Thema vom Tisch. 1 Gruppe darf schreiben die andere nur Lesen.
Lies statt nur der Überschrift auch mal den Artikel. Dort gibt es eine Beschreibung was z.B. mit ACL möglich ist (am Beispiel Urlaubsvertreter-Regelung). Ein weiters gutes Merkmal ist (gem. Artikel), dass man auch hierarchisch weitervererbbare Rechteregelungen treffen kann.
Wenn man eine weitere Grupper für Owner2 oder Group2 oder Other2 einführen würde, wäre dies nicht näherungsweise so flexibel wie die ACL Lösung.
Unsere Admins bemängeln bisweilen dass mit Windows NT / 2000 feinkörnigere Rechtevergaben möglich sind. Mit ACL schliesst Linux nun auch hier mit Windows (langsam) auf.
Die Befehlssyntax finde ich IMHO aber noch recht gewöhnungsbedürftig, wenn man bisweilen nur mit den 3 bereits bekannten Gruppen (Owner, Group, Other) gearbeitet hat.
Ich persönlich finde ACLs als eine wichtige Verbesserung von Linux. Ich arbeite oft an Netware 4.2. Ähnliche Feinkörnige Rechtevergaben, wie sie bei uns einfach gefordert sind (Mehrere User können Verzeichnis einsehen, aber schreiben dürfen nur drei davon, das ganze vererbbar..... Ist nur ein einfaches Problem, viele sind viel Problematischer....) Mit einer einfachen Erweiterung der Userstruktur (wie oben angedeutet) geht das einfach nicht, dafür haben wir schon allein zu viele User/Gruppen/Untergruppen..... Wäre nur schön, wenn man jetzt noch mehrere "Root" hätte..... Bzw. einen User "Root-Äquivalent" machen könnte.....
in haeufigen Faellen sind ACLs garnicht noetig. Man kann z.B. vieles ueber Gruppen-Zugehoerigkeiten loesen... Ausserdem laesst sich einiges ueber das S-bit (fuer die Gruppe) machen.
Also wir haben hier 4 File-Server laufen (unter Linux), keine Probleme auch ohne ACLs...
Und wenn man dann doch ACLs braucht, dann lieber mit XFS... da sind naemlich auch ein Tool zum Sichern dabei ;-)
Was die Superuser-Accounts betrifft, schau Dir mal "sudo" an.
Das ist eigentlich ein Unsinn. Wenn der User im Verz. schreiben kann, so kann er ja auch den Inhalt der Datei löschen, also die Grösse auf 0 setzen, was ja einem delete nahe kommt.
ich find das garnicht unsinnig, ex-anonymous sagt ja nichts davo das vorhandene Dateien geaendert werden duerfen sonder nur neu agelegt oder hineinkopiert. Das wäre schon interessant.
Hast Du da mehr Infos zu ? Ich bin bis jetzt "nur" auf auf rwx bei den ACLs gestoßen, und die man pages bzw. die SGI Seite ist dokutechnisch eher zurückhaltend (oder hab ich was übersehen ? hab nur die FAQ und die man Pages als Doku gefunden).
Ich hab gerade mal auf Google nachgeguckt und einiges zu XFS unter Irix gefunden. Das sollte dann wohl auch fuer die Linux-Version gelten...
Ich hatte erwartet, dass SGI mit "extended attributes" sowas wie die File Flags unter BSD meint.
Hab mich aber warscheinlich geirrt: Die meinen damit wohl, dass man z.B. fuer ein JPEG-Bild einen ASCII-Text mit abspeichern kann, der dann als Attribut hinterlegt ist.
Tja, sieht so aus, als muesste man zu *BSD wechseln, um File Flags zu benutzten :-(
Wäre es nicht geschickter, man würde für das EX3 Filesystem
ein neues Feature einführen, das es ermöglicht, 2 oder mehrere Gruppen eine Datei zuzuweisen?
Also, das man pro Datei, z.b. 2 Gruppen verwenden kann.
Dann wäre das Thema vom Tisch.
1 Gruppe darf schreiben die andere nur Lesen.
Ein weiters gutes Merkmal ist (gem. Artikel), dass man auch hierarchisch weitervererbbare Rechteregelungen treffen kann.
Wenn man eine weitere Grupper für Owner2 oder Group2 oder Other2 einführen würde, wäre dies nicht näherungsweise so flexibel wie die ACL Lösung.
Unsere Admins bemängeln bisweilen dass mit Windows NT / 2000 feinkörnigere Rechtevergaben möglich sind. Mit ACL schliesst Linux nun auch hier mit Windows (langsam) auf.
Die Befehlssyntax finde ich IMHO aber noch recht gewöhnungsbedürftig, wenn man bisweilen nur mit den 3 bereits bekannten Gruppen (Owner, Group, Other) gearbeitet hat.
Mit einer einfachen Erweiterung der Userstruktur (wie oben angedeutet) geht das einfach nicht, dafür haben wir schon allein zu viele User/Gruppen/Untergruppen.....
Wäre nur schön, wenn man jetzt noch mehrere "Root" hätte..... Bzw. einen User "Root-Äquivalent" machen könnte.....
Ok ist ein Hack.
Leg in /etc/passwd einen User mit der selben UID/GID wie root an.
in haeufigen Faellen sind ACLs garnicht noetig.
Man kann z.B. vieles ueber Gruppen-Zugehoerigkeiten loesen...
Ausserdem laesst sich einiges ueber das S-bit (fuer die Gruppe) machen.
Also wir haben hier 4 File-Server laufen (unter Linux), keine Probleme auch ohne ACLs...
Und wenn man dann doch ACLs braucht, dann lieber mit XFS... da sind naemlich auch ein Tool zum Sichern dabei ;-)
Was die Superuser-Accounts betrifft, schau Dir mal "sudo" an.
mfg.
peter
da gibts das attr-command, mit dem sich erweiterte Attribute setzten lassen...
mfg.
peter
sorry, hab mich getaeuscht...
Ich hab gerade mal auf Google nachgeguckt und einiges zu XFS unter Irix gefunden. Das sollte dann wohl auch fuer die Linux-Version gelten...
Ich hatte erwartet, dass SGI mit "extended attributes" sowas wie die File Flags unter BSD meint.
Hab mich aber warscheinlich geirrt:
Die meinen damit wohl, dass man z.B. fuer ein JPEG-Bild einen ASCII-Text mit abspeichern kann, der dann als Attribut hinterlegt ist.
Tja, sieht so aus, als muesste man zu *BSD wechseln, um File Flags zu benutzten :-(
mfg.
peter
schau dir doch mal das verzeichniss /tmp an
jeder darf dateien anlegen, aber nur seine löschen
chmod +t /tmp
> zu *BSD wechseln, um File Flags zu
> benutzten
man 1 chattr
Die implemtation ist zwar nicht so elegant wie die von 4.4, aber immerhin da..
Christoph
http://nxtvepg.tripod.com/index-de.html
Ich wußte garnicht das es sowas gibt, aber ich finde es schlicht und einfach fantastisch - nie mehr TV-Zeitschrift