Coda 2 und SCP laden Dateien mit falscher Berechtigung hoch
4681
Tom Black
Derzeit habe ich einen grundlegenden Ubuntu-Server, der eine Website betreibt. Die Website richtet sich an einige Schüler, die HTML / PHP lernen, und jeder Schüler hat einen eigenen Account mit einem symbolischen Link zum freigegebenen Websiteordner. Da die Schüler gemeinsam an der Website arbeiten, muss jeder Benutzer in der Lage sein, alle Dateien (beispielsweise index.html) zu ändern. Also habe ich eine Webdev-Gruppe erstellt, die alle Schüler mit der Standard-Umask von 0002 in ihrer .bashrc enthält (Dies ermöglicht neu erstellte Dateien als 774). Der freigegebene Ordner gehört der Gruppe Webdev mit einem chmod g + s, sodass neue Dateien / Ordner auch zur Gruppe Webdev gehören.
Das Problem ist, dass die Schüler eine IDE (Coda 2) verwenden. Wenn sie mit der IDE eine neue Datei oder einen neuen Ordner erstellen, verfügt die Datei über die Berechtigungen 644 auf dem Server (nicht für Gruppen beschreibbar). Wenn ich jedoch eine neue Datei durch Verbinden mit Cyberduck (SFTP-Client) erstelle, sind die Dateiberechtigungen 664 (wie sie sein sollten). Also verstehe ich nicht, warum Coda anders wäre.
Nach einigem Ausprobieren glaube ich jedoch, dass Coda zuerst die Datei auf der lokalen Festplatte erstellt und diese dann auf den Server lädt. Auf einem Mac ist standardmäßig eine neu erstellte Datei 644. Wenn der Client eine Datei hochlädt, die bereits 644 ist, bleibt sie auf der Serverseite 644 (umask ist in dieser Situation irgendwie nutzlos). Ich habe auch versucht, ACL-Berechtigungen für diesen Ordner zu erstellen, aber eine über SCP hochgeladene Datei von meinem Mac erhält nicht die Standard-ACL-Berechtigungen.
In Coda gibt es eine Option zum Ändern der Dateiberechtigungen für eine Übertragung. Diese Option scheint jedoch ein chmod auf alle Dateien anzuwenden, die hochgeladen oder gespeichert werden. Wenn einer der Schüler eine von einem anderen Benutzer erstellte Datei ändert, wenn er versucht, die Datei hochzuladen oder zu speichern, versucht Coda, auch einen chmod auszuführen, schlägt jedoch fehl, da dieser Benutzer nicht der Eigentümer der Datei ist.
Meine aktuelle Lösung verwendet bindfs ... Ich mounte den freigegebenen Webordner und bindfs legt Berechtigungen und Gruppeneigentum für neu erstellte Dateien fest. Bindfs scheint jedoch etwas langsam zu sein und ich bin sicher, dass es eine bessere Lösung gibt.
Selbst wenn die Schüler Coda 2 aufgegeben und Mac vim mit scp verwendet haben, verhalten sich die neu erstellten Dateien auf dem Server genauso (644), wie es auf dem Mac standardmäßig ist.
Andere Optionen...
1) Entweder bringe ich den Schülern bei, (ssh / chmod) mit ihrer IDE zu verwenden, um beim Hochladen ihre eigenen Dateiberechtigungen zu ändern.
2) Ich mache, dass alle Macs der Schüler die Standardaufgabe 0002 haben, die Dateien mit den richtigen Berechtigungen hochladen würde.
3) Schreiben Sie ein Mais-Skript, um die Dateiberechtigungen alle 5 bis 15 Minuten zu korrigieren ... (Diese Option ist meiner Meinung nach die schlechteste, wenn die Schüler gleichzeitig zusammenarbeiten).
Gibt es eine Möglichkeit, alle Dateien, die über SCP hochgeladen werden, standardmäßig mit den Dateiberechtigungen 664 zu versehen, obwohl die hochgeladene Datei über eine niedrigere Berechtigung verfügt? (Nach stundenlangem Suchen denke ich nicht, dass dies möglich ist.) Ich denke, ein Mais-Skript ist die beste Option für Anfänger. Wie arbeiten Webentwickler auf größeren Websites zusammen?
Coda lädt tatsächlich lokale Dateien hoch. Wenn Sie keine Hacks wie das jetzt nicht mehr unterstützte / veraltete http://sftpfilecontrol.sourceforge.net verwenden, haben die Dateien die lokalen Berechtigungen. Da OSX überask 022 hat, sind Dateien, die unter OSX erstellt wurden, nicht für Gruppen schreibbar, also 644. Coda lädt das gerne hoch. Wie Sie herausgefunden haben, kann Coda bestimmte Berechtigungen erzwingen, aber es ist nicht fein genug, um anzugeben, dass es nur für neue Dateien ausgeführt werden sollte. Daher werden Fehler beim Speichern vorhandener Dateien angezeigt, die sich nicht im Besitz des Benutzers befinden am häufigsten Fall). Die einzige Möglichkeit, dies zu erreichen, besteht darin, die Benutzer umask unter OSX zu ändern. Erstellen Sie die Datei /etc/launchd-user.confund fügen Sie sie dort ein:
umask 002
Dann neu starten. Anschließend erstellt Coda lokal Dateien und lädt diese hoch. Dateien sind jetzt ordnungsgemäß für die Gruppe schreibbar. In den Coda-Voreinstellungen ist die Option Berechtigungen beim Hochladen festlegen nicht erforderlich.
Im Coda-Voreinstellungsfenster auf der Registerkarte Regeln können Sie die gewünschten Berechtigungen für Dateien festlegen, die über ftp / sftp hochgeladen werden. Der Standardwert ist 644; Es sieht so aus, als könnte das Problem durch das Aktivieren des Kästchens "Schreiben" in der Zeile "Gruppe" behoben werden. Natürlich muss jeder Student dies in seiner eigenen Kopie von Coda tun.
I talked about this in my post... Coda seems to apply a chmod to all files that are saved/uploaded. If the student is modifying a file that he/she doesn't own Coda returns a big fat error. The exact error is "Make sure you have permission to modify this file. This server or file may not allow you to adjust permissions. Double-check that your permissions in the Rules preferences are set correctly."
Tom Black vor 12 Jahren
0
1
Richard Milewski
Das Problem sind nicht die Berechtigungen für die Datei, sondern die Gruppe (n), zu denen Ihre Schüler gehören. Wenn Sie auf dem Webserver-Computer die primäre Gruppe jedes Schülers mit der Gruppe des Webservers (auf Linux-Systemen normalerweise www-data oder apache) und die Standarddateiberechtigungen im Coda-Voreinstellungsbereich auf 660 festlegen, sollten alle Einstellungen korrekt sein .
# usermod -g apache studentUID
oder
# usermod -g www-data studentUID
abhängig davon, welche Linux-Variante Sie auf dem Webserver ausführen.