Zugriffsrechte

[mcfeir]

Ohne ACLs wären Dateien auf NTFS besitzerlos.....

Ja, aber was soll das Hypothetische ? Dadurch, dass ACLs ein integraler Bestandteil von NTFS sind, gibt es eben keine besitzerlosen Dateien. Wie diskutieren hier doch nicht die Frage : Was wäre wenn.

 

[Dualis]

...so viele missverständnisse *g*

also ich meine gelesen zu haben, dass die ACL-funktion in os x (10.5) erst gesondert aktiviert werden muss. (was auch immer "aktiviert" heissen mag, eventuell meint apple damit halt nur, dass man da auch selbst eingreifen kann)

wobei ich es schon interessant finde, dass mac os x das ändern auch programmen gestattet. ist das in etwa so, wie wenn man bei windows bei einer installation gefragt wird, ob das program nur von dem aktuellen oder von allen benutzern benutzt werden darf?

 

[mcfeir]

Was die Überlegenheit von ACLs gegenüber den POSIX-Rechten auf einem Mac-System anbetrifft, findet man hier einen sehr schönen Text, der die unterschiedlichen Fähigkeiten an ein paar einleuchtenden Beispielen demonstriert :

http://arstechnica.com/reviews/os/macosx-10-4.ars/8

 

[maceis]

Nun ja. Was heißt hier schon "Überlegenheit"?
Klar, man hat weitaus mehr und komplexere Möglichkeiten.
Das kann aber auch ein Nachteil sein und sogar ein Sicherheitsrisiko.

Der große Vorteil der POSIX Berechtigungen liegt in ihrer geradezu genialen Einfachheit.
Wenn das so schlecht gewesen wäre, hätten Sie nicht Jahrzehnte überdauert und wären auch heute noch auf vielen Systemen in Ihrer einfachen Pracht völlig ausreichend.
Problematisch wird POSIX dann, wenn es um komplexe Dateisystem- und Eigentümer-/Gruppenstrukturen ins Spiel kommen. Beispiel: Viele Firmen bauen heute Ihre Dateistrukturen als Abbild der Firmenstruktur auf und nicht in Bezug auf die logische Dateiberechtigungsstruktur. Dafür gibt es ja auch gute Gründe. Da sind ACL natürlich besser geeignet.
Trotzdem gilt mE auch hier die alte KISS Regel.

 

[MacMark]

… ich meine gelesen zu haben, dass die ACL-funktion in os x (10.5) erst gesondert aktiviert werden muss. …

Bei 10.5 Leopard sind ACLs per default aktiv. Bei 10.4 Tiger noch nicht, denn da waren sie neu.

@@mcfeir
Hast Du inzwischen Dateien auf Leopard gefunden, die eine ACL haben?

 

[mcfeir]

Problematisch wird POSIX dann, wenn es um komplexe Dateisystem- und Eigentümer-/Gruppenstrukturen ins Spiel kommen.

So komplex muss die Problemstellung gar nicht sein. Wenn ich z.B. einem Benutzer gezielt das Löschen einer Datei verbieten will, ohne dass ich ihm deshalb gleich die Schreibrechte entziehen will, dann geht das nur über ACLs, indem ich z.B. in diesem Fall den Befehl : chmod +a "maceis deny delete" Datei eingebe.

 

[mcfeir]

Hast Du inzwischen Dateien auf Leopard gefunden, die eine ACL haben?

Nein; werden mir nicht angezeigt, ich habe allerdings auf meinem System nur einen einzigen Benutzer; hängt möglicherweise damit zusammen.

Du schreibst ja selbst :

Bei 10.5 Leopard sind ACLs per default aktiv. Bei 10.4 Tiger noch nicht, denn da waren sie neu.

Das verstehe ich so, dass sie bei Leopard immer gesetzt sind.

 

[MacMark]

Nein; werden mir nicht angezeigt …

Hätte mich auch gewundert Es sind keine ACLs gesetzt, weil OS X sind nicht benötigt.

Du kannst aber jederzeit ACEs anhängen an Dateien. Die ACL wir dann zuerst geprüft und wenn kein Eintrag darin paßt, dann werden die POSIX-Rechte der Datei ausgewertet.

KeyWest:~ macmark$ ls -le myfile
ls: myfile: No such file or directory
KeyWest:~ macmark$ echo "hallo" > myfile
KeyWest:~ macmark$ cat myfile 
hallo
KeyWest:~ macmark$ ls -le myfile 
-rw-r--r--  1 macmark  staff  6 Apr  6 11:56 myfile
KeyWest:~ macmark$ chmod +a "owner deny read" myfile 
KeyWest:~ macmark$ ls -le myfile 
-rw-r--r--+ 1 macmark  staff  6 Apr  6 11:56 myfile
 0: group:owner deny read
KeyWest:~ macmark$ cat myfile 
cat: myfile: Permission denied
KeyWest:~ macmark$ chmod -a# 0 myfile 
KeyWest:~ macmark$ ls -le myfile 
-rw-r--r--  1 macmark  staff  6 Apr  6 11:56 myfile
KeyWest:~ macmark$ cat myfile 
hallo

 

[maceis]

So komplex muss die Problemstellung gar nicht sein. Wenn ich z.B. einem Benutzer gezielt das Löschen einer Datei verbieten will, ohne dass ich ihm deshalb gleich die Schreibrechte entziehen will, dann geht das nur über ACLs, indem ich z.B. in diesem Fall den Befehl : chmod +a "maceis deny delete" Datei eingebe.

Das ist zwar richtig, aber man kann jetzt anfangen darüber zu diskutieren, wie sinnvoll das ist und wie oft man es braucht. Denn schließlich kann der Benutzer in dem von Dir geschilderten Fall die Datei auch dadurch vernichten, dass er den Inhalt löscht und die Datei sichert.

Theoretisch lässt sich die Problemstellung übrigens auch in einem reinen POSIX System lösen. Ich gebe aber gerne zu, dass das nicht erstrebenswert ist.

BTW: die ACL Einträge lassen sich problemlos im Terminal anzeigen, z.B.:

ls -le ~/

 

[mcfeir]

die ACL Einträge lassen sich problemlos im Terminal anzeigen...

Ja, aber - so wie MacMark schon richtig sagt -nur wenn auch welche gesetzt sind. In den meisten Fällen sind per default keine gesetzt.

 

[Dualis]

gibt es eigentlich neben sandbox, was offiziell noch net 10.5 unterstützt noch eine weitere möglichkeit acls in einer grafischen oberfläche einzusehen oder zu ändern? (für die nicht-server-version)

 

[MacMark]

… Festplatten-Dienstprogramm die Zugriffsrechte des Volumes überprüfe, … Meldungen angezeigt werden, wie "Die Zugriffsrechte unterscheiden sich ..." oder "Benutzer unterscheidet sich ...". Kann mir jemand sagen, was die Ursache dafür ist? …

Das sind in der Regel aktuellere Rechteeinstellungen, die von der Originalinstallation abweichen. Der Vollständigkeit halber und zur Info wird das erwähnt. In der Regel sind das einfach nur Hinweise und keine Probleme.
http://www.macmark.de/osx_permissions.php

 

[maceis]

@mcfeir

Darum habe ich ja auch ein Beispiel gebracht, wo standardmäßig welche gesetzt sind (zumindest wenn man clean installiert hat).

 

[MacMark]

gibt es eigentlich … eine weitere möglichkeit acls in einer grafischen oberfläche einzusehen oder zu ändern?…

Der Info-Dialog vom Finder erwähnt ACLs, wenn sie vorhanden sind.

Edit: Man kann sie auch mit der Finder-Info ändern und löschen.

Edit2: Die Unterverzeichnisse der User sind beispielsweise besonders geschützt:

KeyWest:~ macmark$ ls -led Documents/
drwx------+ 51 macmark  staff  1734 Mar 21 11:42 Documents/
 0: group:everyone deny delete

Im Finderinfo macht sich dieses Beispiel durch "Name:everyone, Privilege:no access" bemerkbar. Offenbar soll versehentliches Löschen der Standardverzeichnisse verhindert werden damit.

Ich glaube, mit TinkerTool http://www.bresink.de/osx/TinkerTool-de.html kann man die ACLs graphisch setzen. Allerdings läßt sich mit "Tools" auch viel Unfug anstellen, den man ohne sie nicht versehentlich verbrechen würde.

 

[Dualis]

Der Info-Dialog vom Finder erwähnt ACLs, wenn sie vorhanden sind.
Edit: Man kann sie auch mit der Finder-Info ändern und löschen.

ahh ok danke...aber erst einmal setzen kann ich sie nur per terminal ,oder?
(ich will zb auf einem nas, worauf mehrere leute zugriff haben, verhindern, dass dateien gelöscht werden können)

 

[MacMark]

Sticky bit setzen

Kannst aber auch mit der Finderinfo ACEs setzen. Habe ich grad probiert, funktioniert: "+" klicken, gewünschte User wählen und Recht setzen. Das landet dann als ACE in der ACL.

 

[Dualis]

hmm, aber in der finder-info stehen die rechte so verwirrend da...zb das mit "everyone: keine rechte"..da brauch ich schon was eindeutigeres ala deny delete *g*

 

[rita]

fachsimpeleien hin oder her, was sagt mir so eine meldung vom
festplattendienstprogramm: "die zugriffssteuerungsliste wurde gefunden, jedoch nicht für library erwartet"
bzw. von onyx: "ACL found but not expected on library"

is das schlecht oder gut oder wurscht, muss ich was tun...?????

danke, rita

 

[MacMark]

Sieht mir nach Statusmeldung aus, kein Fehler. Wurde mit einem Systemupdate wohl die ACL hinzugefügt.

"Any message that starts with: 'ACL found but not expected on...'."
Solution: You can safely ignore these messages. They are accurate but not a cause for concern.

Apropos OnyX: Mein Schwager hat erst gestern sein System mit "Caches leeren" per OnyX zerschossen. Die Maus ging danach nicht mehr und ich war zu weit weg um direkt zu helfen. Finger weg von OnyX!

 

[mcfeir]

Apropos OnyX: Mein Schwager hat erst gestern sein System mit "Caches leeren" per OnyX zerschossen. Die Maus ging danach nicht mehr und ich war zu weit weg um direkt zu helfen. Finger weg von OnyX!

Das ist die Crux bei den meisten Optimierungstools, egal ob unter Mac OS X oder unter aktuellen NT-Windows. Die Betriebssysteme sind meistens in sehr elaborierter Weise selbststeuernd. Wer da meint noch optimieren zu können, wird in vielen Fällen nur verschlimmbessern.