• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

Rechte vererben

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Ein "umask 2" sollte auch helfen, weil damit Dateien -rw-rw-r-- bekommen und Verzeichnisse drwxrwxr-x. Zusammen mit dem "set-groupID flag" sollte das den Job tun.
 

strykerkr

Gala
Registriert
08.11.07
Beiträge
52
Hallo,
ich habe nun auch im englischen Foren gepostet und so wie es aussieht scheint dies ein Bug in ACL zu sein. Das Problem tritt anscheinend dadurch auf das Textdateien und andere Files erst in einem temporaeren Verzeichnis erzeugt werden und dann ueber rename quasi verschoben werden. Dabei werden die Rechte dann nicht mehr geaendert.
Ich habe aber noch eine kurze Frage. Ich habe nun ziemlich viel chmod rumgespielt und nun tauchen die Gruppen teilweise doppelt auf. Gibt es eine einfache Moeglichkeit die Rechte wieder auf einen einzigen User zurueck zu setzen.

mfg

Stephan
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
... scheint dies ein Bug in ACL zu sein. Das Problem tritt anscheinend dadurch auf das Textdateien und andere Files erst in einem temporaeren Verzeichnis erzeugt werden und dann ueber rename quasi verschoben werden. Dabei werden die Rechte dann nicht mehr geaendert. ...
Welcher ACL-Regel widerspricht das denn?
 

strykerkr

Gala
Registriert
08.11.07
Beiträge
52
Welcher ACL-Regel widerspricht das denn?

TextEdit actually doesn't write the file into your directory, that's why. Instead, it writes a file into your $TMPDIR, then uses rename() to move the file into the directory you specified. As someone pointed out earlier, file moves into a directory with an ACL won't inherit the ACL.

Kann mir jemand sagen wie ich die ganzen EIntraege mit local->custom wieder los werde. Habe alle versucht aber die Rechte lassen sich nicht mehr entfernen. Ausserdem wuerde ich gerne die USer "everyone' ueber ein Skript entfernen. Geht das irgendwei?

mfg

Stephan
 

Anhänge

  • Picture 1.png
    Picture 1.png
    18,2 KB · Aufrufe: 219

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
TextEdit actually doesn't write the file into your directory, that's why. Instead, it writes a file into your $TMPDIR, then uses rename() to move the file into the directory you specified. As someone pointed out earlier, file moves into a directory with an ACL won't inherit the ACL. …

Es ist also kein "Bug in ACL", sondern korrektes der Spezifikation entsprechendes Verhalten.
 

strykerkr

Gala
Registriert
08.11.07
Beiträge
52
Es ist also kein "Bug in ACL", sondern korrektes der Spezifikation entsprechendes Verhalten.

Ich finde schon es ist irgendwie ein Bug, oder. Ich meine ich habe gesagt das alle Dateien die in diesem Ordner erzeugt werden die Rechte erben sollen. Das wuerde auch ein move mit rename einschliessen.

mfg

Stephan
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Die ACL wird beim Erzeugen des Objektes geerbt laut der Regel. Erzeugen ist ungleich Verschieben und ungleich Umbenennen. Die Regel paßt offenbar nicht zu dem, was Du erreichen willst.

PS: Die Gruppe "everyone" ist das, was man bei POSIX-Rechten als "other" vorfindet und was als dritte Spalte neben Eigentümer und Gruppe auftaucht. Diese Gruppe selbst sollte man nicht entfernen.

PPS: Die ACEs kannst Du als ausreichend privilegierter Benutzer nach Aufklicken des Schlößleins mit Minus löschen. Oder mit ebensolchem Benutzer und chmod. Siehe man chmod.
 

strykerkr

Gala
Registriert
08.11.07
Beiträge
52
Die ACL wird beim Erzeugen des Objektes geerbt laut der Regel. Erzeugen ist ungleich Verschieben und ungleich Umbenennen. Die Regel paßt offenbar nicht zu dem, was Du erreichen willst.

Ja leider, ich habe es jetzt erstmal mit einem Login Script geregelt das ist zwar nicht so schoen aber tut den Job.

PS: Die Gruppe "everyone" ist das, was man bei POSIX-Rechten als "other" vorfindet und was als dritte Spalte neben Eigentümer und Gruppe auftaucht. Diese Gruppe selbst sollte man nicht entfernen.

OK. Ich moechte nur verhindern das in einem Netzwerk alle den Ordner Shared lesen duerfen aber anscheinend ist das nicht so.

PPS: Die ACEs kannst Du als ausreichend privilegierter Benutzer nach Aufklicken des Schlößleins mit Minus löschen. Oder mit ebensolchem Benutzer und chmod. Siehe man chmod.

Leider geht das mit loeschen nicht. Alle Benutzer die ueber die GUI hinzugefügt habe kann ich loeschen aber nicht die die ich ueber die Konsole deklariert habe :(.


mfg

Stephan
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
man chmod ;)

Beispiel:
Code:
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

Im Web:
http://www.manpagez.com/man/1/chmod/

Gehe bis zu der Stelle
The -a mode is used to delete ACL entries
:)
 

strykerkr

Gala
Registriert
08.11.07
Beiträge
52
man chmod ;)

Beispiel:
Code:
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
Im Web:
http://www.manpagez.com/man/1/chmod/

Gehe bis zu der Stelle :)

Der hier wars ;)

chmod -R -N /Users/Shared/

Thx

Stephan
 

strykerkr

Gala
Registriert
08.11.07
Beiträge
52
Der beseitigt die ganze ACL. Allerdings haben alle User bestimmte ACEs standardmäßig dranhängen.

Das ist schon OK da ich ja beim nächsten Login das Script ausführe was die ACLs dann wieder für alle setzt. In den User Verzeichnissen selbst habe ich nichts verändert nur in dem Verzeichnis Shared.

mfg

Stephan
 

cyberms

Erdapfel
Registriert
28.07.08
Beiträge
5
Hallo,

ich verfolge die Diskussion mit regem Interesse. Ich habe das selbe Problem. Ich möchte gerne ein Ordner für Fotos erstellen. Auf diesen Ordner soll meine Frau und ich gleichermassen zugriff haben. Beim erstellen neuer Fotos sollen beide direkt alle Rechte haben. Unter Windows ist die Rechtevererbung kein Thema. Unter OSX sieht es doch leider anders aus. Ich habe bisher alle Tipps beherzigt, leider ohne Erfolg. Wieso ist das so ein grosses Problem unter Unix? Sorry wenn ich so Frage, bin ein Umsteiger .-) Über eine Lösung würde ich mich freuen.

mfg

cyberms
 

strykerkr

Gala
Registriert
08.11.07
Beiträge
52
Hallo,

ich verfolge die Diskussion mit regem Interesse. Ich habe das selbe Problem. Ich möchte gerne ein Ordner für Fotos erstellen. Auf diesen Ordner soll meine Frau und ich gleichermassen zugriff haben. Beim erstellen neuer Fotos sollen beide direkt alle Rechte haben. Unter Windows ist die Rechtevererbung kein Thema. Unter OSX sieht es doch leider anders aus. Ich habe bisher alle Tipps beherzigt, leider ohne Erfolg. Wieso ist das so ein grosses Problem unter Unix? Sorry wenn ich so Frage, bin ein Umsteiger .-) Über eine Lösung würde ich mich freuen.

mfg

cyberms

Moin,
leider sieht es wirklich so aus als gäbe keine andere Lösung. Ich habe es so gelöst das ich das iPhoto und iTunes Archiv unter "Alle Benutzer" ablege und dann beim Login ein Script ausfuehre das die Rechte jedes Mal neu setzt. Ist zwar nicht besonders Elegant aber funktioniert.

mfg

Stephan
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Unter "Für alle Benutzer" ablegen und falls das nicht genügt, alle betroffenen Dateien markieren, Infobox aufrufen und auf einen Schlag alle Rechte ändern auf "Andere ... Lesen & Schreiben".

Diese Trennung von Benutzern macht eine Säule der Sicherheit unter Unix aus. Wenn jeder User in Deinen Dateien rumpfuschen kann, dann verbreitet sich ein Schädling genauso leicht. Was andere User können, ist auch für einen Schädling eine Einladung.
 

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
Die ACL wird beim Erzeugen des Objektes geerbt laut der Regel. Erzeugen ist ungleich Verschieben und ungleich Umbenennen.
Und genau das *ist* ein Bug. Es hat nämlich irrelevant zu sein, ob ein neues Dateisystemobjekt durch verschieben, linken, umbenennen oder sonstwas entsteht. Diese Unterscheidung gilt für die Posix/BSD Legacy Permissions, nicht aber für Posix/ACL. OS X hält sich auf HFS+ Volumes an die Dateisystem-interne FSID statt an den Namen, und das ist nicht statthaft, da nicht portabel.
Da ist immer noch der Wurm drin.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Wenn eine verschobene Datei die ACL vom Mutter-Ziel-Ordner erben soll, dann ist noch die Frage was passiert mit einer ACL, die sich bereits schon an der zu verschiebenden Datei befindet? Werden die neuen ACEs oben eingefügt (und haben dadurch Vorrang) oder unten in der ACL? Werden die bisherigen ACEs gelöscht?

Bei einer frischen erstmals erzeugten Datei stellen sich solche Fragen nicht.
 

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
Werden die bisherigen ACEs gelöscht?
Irrelevant. Der Fehler besteht darin, dass Cocoa und Carbon ihre Temporärdateispielchen mit einer sehr unorthodoxen Methode durchführen, die rein HFS-spezifisch realisiert und damit vor dem Rest des Systems vollständig zu verbergen ist, was aber misslingt. Unter Umgehung der BSD-üblichen Prozedur werden hier einfach die Extents-Listen im Directory-Tree vertauscht, wenn zwei Obekte auf "magische" Weise ihren Platz tauschen sollen. Dummerweise werden hier bisher nur der Daten- und der Resourcefork korrekt behandelt, der neu hinzugekommene Attributes Fork macht den Tausch u.U. nicht wie erwartet mit. Der bleibt in einigen (unklaren) Situationen an der FSID des Objekts "kleben", was dazu führt dass Daten und Attribute eines Objekts irreparabel verdreht und ab da zu zwei verschiedenen Objekten werden, die keinen Bezug mehr zueinander zu haben scheinen.
Das hat zur Folge, dass zB beim Speichern mit TextEdit zwar die Inhalte und "traditionellen" Metadaten korrekt gesetzt sind, die dazugehörigen erweiterten Attribute aber verbleiben an der Temporärdatei und werden zusammen mit ihr gelöscht.