Lokalisierung von Verzeichnisnamen und Rechtevererbung im Dateisystem bei Freigaben

[SonicFlash]

Habe mir irgendwie die Drop Box (also den Briefkasten) in meinen öffentlichen Ordner zerschossen. Wie genau ich das hinbekommen habe weiss ich zugegeben auch nicht. Resultat war jedoch das kein anonymer Benutzer mehr in den Ordner schreiben konnte und wenn ich versucht habe für everyone das Schreiben (Briefkasten)-Recht zu setzen, ist dieses immer wieder sofort zurückgesprungen.

Aufgrund mangelnder Ideen habe ich den Ordner inzwischen gelöscht und versucht ihn "von Hand" nachzubilden.
Drei Einstellungen stimmen aber noch nicht.

1. In der deutschen Mac OS X Version hieß der Ordner "Briefkasten" (in der GUI), obwohl er eigentlich "Drop Box" (schaut man in die Konsole erkennt man dies) heisst. Wie vergibt man für die GUI einen anderen Namen als das Verzeichnis tatsächlich im Dateisystem heisst? Bzw. wie kommt es zu dieser Lokalisierung des Namens?

2. Wenn ich nun eine Datei von einem fremden System in meine neue "Drop Box" lege, wird diese unter dem Benutzer "nobody" erstellt. Natürlich sollte diese aber unter dem Benutzernamen des Inhabers der Drop Box angelegt werden. Was muss ich einstellen damit dieses wieder korrekt funktioniert?

3. Das unwichtigste: Das Icon des Ordners. Normalerweise hat der Briefkasten in der GUI ein leicht modifiziertes Standardordner-Icon (dieser kleine Pfeil rechts unten). Wie setzt man das anzuzeigende Icon?

Vielen Dank vorab.

 

[Rastafari]

Wie vergibt man für die GUI einen anderen Namen als das Verzeichnis tatsächlich im Dateisystem heisst?

Im Falle der vom System bereitgstellten Standardordner (was man so alles in einem frisch angelegten Konto vorfindet) ist das simpel.

touch ${HOME}/Public/.localized;
touch ${HOME}/Public/Drop\ Box/.localized;

Bzw. wie kommt es zu dieser Lokalisierung des Namens?

Bei Ordnern mit den ganz speziellen Standardnamen genügt es, durch diese enthaltene unsichtbare Datei das Verfahren zu triggern.
(Bei selbst erstellten Ordnern muss man noch zusätzlich Textlisten mit den jeweils übersetzten Namen erstellen)

Wenn ich nun eine Datei von einem fremden System in meine neue "Drop Box" lege, wird diese unter dem Benutzer "nobody" erstellt. Natürlich sollte diese aber unter dem Benutzernamen des Inhabers der Drop Box angelegt werden.

Nein, auf gar keinen Fall. Würde das tatsächlich geschehen, hättest du ein unlösbares Sicherheitsproblem.
Das beschriebene Verhalten ist absolut normal und völlig beabsichtigt.
Ausser der Systemsoftware selbst (sprich: dem "root-Benutzer") hat absolut niemand das Recht, ein Objekt unter falschem Eigentümer zu erstellen oder diesen abzuändern.
Wenn der entfernte Benutzer dem System nicht bekannt ist (wenn es seine Anmeldedaten nicht selbst verwaltet), dann läuft der Remote-Zugriff unter "Guest" oder "nobody".

Das Icon des Ordners. Normalerweise hat der Briefkasten in der GUI ein leicht modifiziertes Standardordner-Icon (dieser kleine Pfeil rechts unten). Wie setzt man das anzuzeigende Icon?

Das erscheint von alleine, sobald der Ordner die entsprechenden korrekten Zugriffsrechte hat.
Geht furchtbar simpel im Terminal (den Briefkastenordner solltest du vorher erst entleeren):

cd;
chmod -RN Public;
chmod -R u=rwX,go=u-w Public;
chmod [COLOR="Red"]7[/COLOR]33 Public/Drop\ Box;
chmod +a "group:everyone deny delete" Public;

# Beim nächsten mal anmelden sieht alles wieder grün aus

 

[SonicFlash]

Vielen Dank!

Eine Anschlussfrage habe ich aber noch. Bei den Sicherheitsbedenken gebe ich Rastafari recht, jedoch finde ich es irgendwie befremdlich das ich nicht einmal das Recht habe die dort abgelegten Dateien umzubenennen.

Ich meine dass das Verhalten bei einem "ordentlich" installiertem System anders war. Hat die Gruppe "stuff" noch das Schreibrecht bei den neu angelegten Dateien (wie lege ich das fest?), aktuell kann ich als Besitzer der Drop Box die Dateien nicht einmal umbenennen.

Wie ist sonst der gedachte Workflow bei Eingängen über die Drop Box? Daten kopieren und anschließend löschen? Ich bin der Meinung das ich die Dateien früher verschoben und trotzdem umbenannt bekommen habe.

 

[Rastafari]

jedoch finde ich es irgendwie befremdlich das ich nicht einmal das Recht habe die dort abgelegten Dateien umzubenennen.

Mea culpa. Fehlerteufel stecken überall. Korrigiert.

 

[Reinard]

Falsche Rechte im Briefkasten/Drop Box

Hallo, ich habe dasselbe Problem, aber nichts von den Erklärungen verstanden. Fakten:

1. Wenn auf dem Ziel-Mac der Sender des Quell-Macs ebenfalls bekannt ist, funktioniert die Übertragungen und Weiterverarbeitung der Dateien aus dem Briefkasten heraus.

2. Wenn der Benutzer im Ziel-Mac unbekannt ist, liegen die Daten zwar im Briefkasten, ich damit jedoch nichts anfangen, da das System immer meldet, ich hätte nicht die richtigen Zugriffsrechte. Mit chmod gelingt die Änderung der des Besitzernamens nicht, nur mit sudo chown.

Hier liegt sicher ein Fehler seitens Apple vor. Logisch MUSS es so sein, dass wenn etwas in meinem Briefkasten liegt, dass ich dann zum Besitzer werde, Unix hin oder her.

 

[Rastafari]

Hallo, ich habe dasselbe Problem, aber nichts von den Erklärungen verstanden.

Vor allem wohl den Hinweis auf das "unlösbare Sicherheitsproblem" nicht.
Sonst würdest du dich für solche Sätze in Grund und Boden schämen:

Logisch MUSS es so sein, dass wenn etwas in meinem Briefkasten liegt, dass ich dann zum Besitzer werde, Unix hin oder her.

Ich wiederhole:
Unter gar keinen Umständen darf das so sein.
Der Effekt wäre, dass jeder beliebige Client aus dem Netz auf deinem Rechner jedes beliebige Programm mit beliebigen Privilegien starten könnte. Rummsbumms!

2. Wenn der Benutzer im Ziel-Mac unbekannt ist, liegen die Daten zwar im Briefkasten, ich damit jedoch nichts anfangen, da das System immer meldet, ich hätte nicht die richtigen Zugriffsrechte.

Ein deinem System völlig unbekannter Benutzer kann diesen Ordner gar nicht erst sehen, also auch nichts dort ablegen.
Um den "Public" Ordner im Netz sehen und ihn als Freigabe mounten zu können, ist mindestens die Anmeldung als "Gast" nötig.
Und "Gast" ist deinem System sehr wohl bekannt.

Mit chmod gelingt die Änderung der des Besitzernamens nicht, nur mit sudo chown.

Mit chmod ist es noch nie irgendjemandem gelungen, den Eigentümer zu verändern.
chmod und chown sind zwei paar Stiefel mit völlig verschiedener Bedeutung.

Ich wiederhole noch einen Satz:
> Ausser der Systemsoftware selbst (sprich: dem "root-Benutzer")
> hat absolut niemand das Recht, ein Objekt unter falschem Eigentümer
> zu erstellen oder diesen abzuändern.

 

[Reinard]

Vor allem wohl den Hinweis auf das "unlösbare Sicherheitsproblem" nicht.
Sonst würdest du dich für solche Sätze in Grund und Boden schämen:

Ich wiederhole:
Unter gar keinen Umständen darf das so sein.
Der Effekt wäre, dass jeder beliebige Client aus dem Netz auf deinem Rechner jedes beliebige Programm mit beliebigen Privilegien starten könnte. Rummsbumms!


Ein deinem System völlig unbekannter Benutzer kann diesen Ordner gar nicht erst sehen, also auch nichts dort ablegen.
Um den "Public" Ordner im Netz sehen und ihn als Freigabe mounten zu können, ist mindestens die Anmeldung als "Gast" nötig.
Und "Gast" ist deinem System sehr wohl bekannt.


Mit chmod ist es noch nie irgendjemandem gelungen, den Eigentümer zu verändern.
chmod und chown sind zwei paar Stiefel mit völlig verschiedener Bedeutung.

Unabhängig davon, dass hochnäsige Belehrungen die Verständlichkeit nicht ohne weiteres steigern:

1. »chmod« war mein (Tipp)-Fehler, ergibt sich eigentlich aus dem Zusammenhang, sorry.

2. Das Problem ist exakt dieses, DASS eine GAST-Anmeldung NICHT erforderlich ist und ein dem System unbekannter Benutzer den Briefkasten sieht und ihn beschicken kann. Die Dateien haben den Benutzer »nobody« mit »rwx« und die Gruppe »MeinBenutzername« mit »r«. Praktisch stimmt das nur eingeschränkt: Ich kann danach die Dateien zwar kopieren aber nicht öffnen, auch nicht nach dem Kopieren, da sich in den Rechten nichts ändert.

Erst nach

sudo chown [MeinBenutzername] *.*
chmod u=rwx,go=r *.*

ist alles in Ordnung. Und das ist ein Fehler im System. Wenn ich gemäss der Anzeige mit »ls -ls« Leserechte habe, dann muss ich die Datei öffnen können. Und diese Problematik versuchte ich hier zur Klärung darzustellen. Und die konnte bisher keiner durchleuchten.

Dass ich das Problem dennoch alleine lösen konnte, liegt in meiner Unkenntnis, für die ich mich (siehe Anfangszitat) »in Grund und Boden schäme« begründet.

Ciao.

 

[Rastafari]

Das Problem ist exakt dieses, DASS eine GAST-Anmeldung NICHT erforderlich ist und ein dem System unbekannter Benutzer den Briefkasten sieht und ihn beschicken kann.

Anmeldungen werden nur von bekannten Benutzern oder (nur wenn das in den Systemeinstellungen/Benutzer so gestattet wurde) durch "Gast" akzeptiert. Andere Anmeldungen am System sind unmöglich und werden mit Fehlermeldung zurückgewiesen.
Gänzlich unbekannte Benutzer haben keinerlei Zugriff auf den Computer.
(Wenn du das Gegenteil behauptest: Los, leg mir sofort was in meinen Briefkasten!)

Ich kann danach die Dateien zwar kopieren aber nicht öffnen

Den Inhalt einer Datei zu kopieren ohne diese dabei zu öffnen ist ebenfalls unmöglich.

auch nicht nach dem Kopieren, da sich in den Rechten nichts ändert.

Zum dritten mal ein 'unmöglich':
Eigentümer der Kopie ist immer der Ersteller der Kopie, also du selbst.
Nur der Superuser 'root' kann Objekte kopieren und dabei alle Berechtigungen beibehalten.

sudo chown [MeinBenutzername] *.*
chmod u=rwx,go=r *.*

Unter Unix wählt man alle Objekte eines Ordners nicht mit *.* sondern mit *

Wenn ich gemäss der Anzeige mit »ls -ls« Leserechte habe, dann muss ich die Datei öffnen können.

Das kannst du auch.
(obwohl das 's' hier völlig sinnfrei ist)
Es sei denn (Ausnahmefall), dass eine auf die Datei gesetzte ACL (mit vorrangiger Priorität) dir das ganz explizit untersagt.
Zu sehen mit: 'ls -le'

Im 'normalen' Long-Listing werden ACLs nur verkürzt durch ein '+' im Anschluss an die 'Unix' Zugriffsrechte dargestellt, also zB so:
ls -ld /Appl*
drwxrwxr-x+ 142 root admin 4828 16 Feb 20:56 /Applications

Mit "ausgeklappten" ACLs ergibt sich folgendes Bild:
ls -lde /Appl*
drwxrwxr-x+ 142 root admin 4828 16 Feb 20:56 /Applications
0: group:everyone deny delete

 

[Reinard]

Fakten sind nun mal Fakten

Vielleicht kann ja mal jemand anderes als dieser Klugscheisser antworten. Fakten sind etwas anderes als theoretisches Wunschdenken. Ich halte meine Darstellung weiterhin für 100% korrekt und bitte dafür um eine Erklärung:

Nach dem Transfer der Dateien haben sie folgende Eigenschaften

http://emberapp.com/reinard/images/briefkasten-2
http://emberapp.com/reinard/images/briefkasten-1

Eventuell noch die Ergänzung: Der sendende Benutzer ist mit seinem Mac im lokalen Netzwerk.

 

[salome]

Gibt es nicht über  I die Einstellungen "Eigentümer auf diesem Volumen ignorieren" ?
Würde es nützen, wenn du das auf dem Quell-Mac einstellst?