10.11.6 Server - Gruppenrechte-Problem

Mi_Ka

Idared
Registriert
10.11.16
Beiträge
26
Und eigentlich sollte diese Problem zwischen 10.11.6 und 10.6.8 nicht mehr existieren ... das schien es aber schon mal gegeben zu haben. Aber selbst der Apple-Support meint, dass muss gehen.

Sorry ... die vorherige Antwort ist teilweise so nicht richtig ... das Hauptproblem ist in die Jahre gekommene Software, welche aber anstandslos läuft. Deswegen gibt es hier seitens der GL klare Bedenken gegen MacOSx-Client-Upgrades.
 
Zuletzt bearbeitet von einem Moderator:

u0679

Moderator
AT Moderation
Registriert
09.11.12
Beiträge
7.332
GL klare Bedenken gegen

kann man verstehen aus Kostengründen, aber allein aus Sicherheitsgründen (nicht mehr vorhandene Updates für 10..6.x) sollte ein Update durchgeführt werden. Das würde ich der GF nochmal eindrücklich darstellen.
Auch die Kosten für die "IT Probleme" werden dann ja geringer. Denn dann sollte Dein Problem z.B. nicht mehr bestehen.
 

Mi_Ka

Idared
Registriert
10.11.16
Beiträge
26
Ausgangspunkt dieser Aktion war ein defektes RAID5 ... zwei defekte Platten und ein von zweien marodes Netzteil (schwankende Spannungen laut Log) in diesem RAID. Die Datenrettung war auch mit einem vorhandenen Backup null Problem. Da ich hier in einer Halbtagsstelle angestellt bin und grundsätzlich seitens der GL finanziell keine großen Sprünge gemacht werden können, stehe ich jetzt nur vor diesem Zugriffsproblem. Eigentlich habe ich zwar schon mit der Lisa II in den Achtzigern angefangen, bin aber mehr der SunOS/Solaris2- und Linux-Anwender und wahrlich ein alter Arbeitnehmer.
 

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
Und was ich ganz und gar nicht verstehe ... wenn ich mich remote via Terminal und ssh auf dem Server als admin einlogge, habe ich ja den gleichen Effekt drwxr-xr-x beim Erstellen eines Ordners. Mache ich direkt lokal am Server ist alles i.O.. Also ist nur der Netzwerk-Zugriff wohl das Problem.
Die Konfiguration in /etc/launchd-user.conf gilt ausschliesslich für lokale Sitzungen.
Genauer gesagt, für die GUI und alles was daraus gestartet wird.
Niemals für remote-Dienste wie ssh oder afp

Entfernte Anmeldungen via ssh führen üblicherweise die Benutzer-Standardshell aus, idR ist das bash
Und in einer Shell kann man seine umask wahlfrei selbst definieren - per 'umask' Kommando
Dieses kannst du zB in eins der Startskripte der bash einbauen, entweder auf per-Benutzer-Basis oder global.
Eine Anmeldung per ssh kannst du im Skript zB dadurch identifizieren, dass dort im Environment die Umgebungsvarialble SSH_CONNECTION gesetzt ist (bei lokalen Logins ist das nicht der Fall).
Deren Existenz (und ggf auch Inhalt) kannst du im Skript auswerten um zu bestimmen, ob für diese Shell eine neue umask gesetzt werden sollte oder nicht.
Hilfreich?
 

Mi_Ka

Idared
Registriert
10.11.16
Beiträge
26
Wenn Du mir jetzt noch BITTE sagen könntest, in welchen Dateien ich jetzt für die User die umask ändern muss, wäre ich Dir extrem dankbar.

Unter Solaris und Linux steht das ja im Home-Verzeichnis des Users ... unter MacOSX ???

Es sollte ja wohl .bash_profile sein ... nur wo für den allgemeinen Zugriff ???
 
Zuletzt bearbeitet von einem Moderator:

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
Bash kennt auf allen Systemen die gleiche Startup-Prozedur.
Brauche ich also nicht viel dazu zu schreiben, nur ein Hinweis:
man bash ---> INVOCATION
...erläutert das alles.
Hilfreicher?
 

Mi_Ka

Idared
Registriert
10.11.16
Beiträge
26
Aber ist die bash auch für die Netzwerkzugriffe auf die Volumen zuständig ? Das erschließt sich mir nicht.
 
Zuletzt bearbeitet:

Mi_Ka

Idared
Registriert
10.11.16
Beiträge
26
Irgendwie bin ich jetzt gerade völlig perplex ... ich mounte ganz normal via Finder ein freigegebenes Volume vom MacOSX-Server. Wenn ich jetzt via Terminal am MacOSX-Client ein ls -la in /Volumes ablasse, dann steht beim entsprechenden gemounteten Volume ein drwx------. Extrem großes Fragezeichen über meinem Kopf.
 

Marcel Bresink

Hadelner Sommerprinz
Registriert
28.05.04
Beiträge
8.541
Mache ich das Gleiche am 10.6.8-MacOSX-Client als gleicher User "Mitarbeiter" via Terminal auf das gemountete (aber gleiche) Volumen/Verzeichnis, dann ergibt mkdir das nicht gewünschte Ergebnis drwxr-xr-x. UID und GID sind gleich und korrekt.

Und was hat das jetzt mit dem Problem zu tun? Das sind POSIX-Rechte, die Du in Deiner speziellen Konfiguration nicht einsetzen kannst. Es war ganz am Anfang doch geklärt, dass Du ACL-Rechte einsetzen musst.

Nochmal: Auch wenn das zweite "w" bei "drwxr-xr-x" fehlt, heißt das nicht, dass Gruppen dort kein Schreibrecht hätten. Du kannst beliebig vielen (!) Gruppen schon seit Mac OS X 10.4 ein sich vererbendes Schreibrecht erteilen. Dazu musst Du nur Zugriffssteuerungslisten verwenden.
 

Mi_Ka

Idared
Registriert
10.11.16
Beiträge
26
Leider ist drwxr-xr-x genau das Problem, worauf mich die Anwender nach der Inbetriebnahme des neuen 10.11.6 MacOSX-Servers hingewiesen haben ... sie können halt leider nur eingeschränkt was machen ... sonst wäre ich auch nicht auf diese Problematik aufmerksam geworden. Ändere ich es händisch, geht es ja. Aber das kann es ja auf Dauer nicht sein. Und das Thema Zugriffssteuerungslisten habe ich jetzt schon Minimum zweimal nach Deinem Tip gemacht.

Wenn also User xyz1 einen Ordner mit Dateien anlegt, dann können die anderen User zwar darauf zugreifen, aber nichts ändern oder gar löschen.
 
Zuletzt bearbeitet:

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
Aber ist die .bash auch für die Netzwerkzugriffe auf die Volumen zuständig ?
Nein, das macht der afp-Dienst.
Der verhält sich völlig agnostisch gegenüber Posix-Rechten, weil er zB auch völlig kompatibel mit Geräten bleiben will, die gar keine Unix-typischen Benutzerkonten und -berechtigungen kennen.
"umask" Vorgaben akzeptiert dieser Server daher nicht.
Hierfür ist also eine entsprechende ACL auf den freigegebenen Ordnern/Dateien notwendig.

Was du dafür brauchst ist ein "Gruppenordner" als Freigabe.
Erstellst du einen solchen mit der "Server.app", in den Einstellungen einer bestimmten Benutzergruppe, wird er automatisch mit einer ensprechenden ACL neu angelegt.
Willst du dieses Verhalten dagegen auf einem von dir selbst manuell erstellten Freigabeordner haben, bzw auf einem bereits existierenden, dann musst du entsprechende ACLs selbst generieren.

Beispiel:
Die Gruppe der Benutzer die solche "besseren" Zugriffrechte erhalten soll ist $GRP
Der freizugebende Ordner auf dem Server ist $FLD
(FLD existiert bereits und hat schon Inhalte, daher braucht es mehrere Kommandos. Weil:
Vererbte Rechte übertragen sich nicht von alleine auf bereits vorhandenes unterhalb von $FLD, da muss nachgeholfen werden.
Nur die später dort ganz neu erstellten Objekte erben automatisch alles, was es zu erben gibt.
Merke: Das kopieren von Inhalten erschafft solche neuen Objekte, aber simples verschieben/umbenennen nicht.)

sudo chown root:$GRP "$FLD"
sudo chmod 775 "$FLD"

## evtl. bereits vorhandene ACLs
## in diesem Baum komplett eliminieren ???
sudo chown -RN "$FLD"
## ...muttu selber wissen, was du dort schon getan hast...?


sudo chmod +a "group:$GRP:allow \
delete,read,write,append,
list,add_file,add_subdirectory,\
readattr,writeattr,readextattr,writeextattr,readsecurity,\
only_inherit,directory_inherit,file_inherit" "$FLD"

sudo chmod +a "group:$GRP:allow \
execute,search,only_inherit,directory_inherit" "$FLD"

sudo chmod -R +ai "group:$GRP:allow \
delete,read,write,append,
list,add_file,add_subdirectory,\
readattr,writeattr,readextattr,writeextattr,readsecurity,\
directory_inherit,file_inherit" "$FLD"/* "$FLD"/.[^.]* "$FLD"/..?*

sudo find -x "$FLD" -mindepth 1 -type d -exec \
chmod +ai "group:$GRP:allow \
execute,search,directory_inherit" {} +



Ich weiss - sieht dreckskompliziert aus.
Unter uns, ein Geheimnis: Das isses auch.
Sagte ich schon, dass ACL (imho) die dümmste Erfindung seit dem elektrischen Flaschenöffner sind?
Naja, du siehst ja selber was man da aufwenden muss, um ein rundum "sauberes" Verhalten hinzubekommen.
Not as cool as it could be, if ...
... würde man von Anfang an einen Server nur mit der Server.app aufsetzen und erst danach mit Daten befüllen.
Und natürlich auch Benutzer und Gruppen vom Server verwalten lassen, nicht von den lokalen Clients selbst - dafür wäre er ja in erster Linie da. (Beim nächsten Mac weisst du's schon vorher.)
 

Mi_Ka

Idared
Registriert
10.11.16
Beiträge
26
Jetzt macht das natürlich Sinn ... da muss ich morgen wohl noch mal ran. Es war ja die Situation, dass am alten 10.4.x-Server das 10 Jahre alte RAID5 rumzickte. Da noch ein nicht eingesetztes RAID1 rumstand, wurde am 10.4er halt rüber kopiert ... und erst danach kam aus Gründen der Geschwindigkeit der 10.11.6-Server zum Einsatz.
 

Marcel Bresink

Hadelner Sommerprinz
Registriert
28.05.04
Beiträge
8.541
Und das Thema Zugriffssteuerungslisten habe ich jetzt schon Minimum zweimal nach Deinem Tip gemacht.

Nein, zum einen scheinst Du der falschen Gruppe Schreibrecht erteilt zu haben, zum anderen schaust Du Dir immer nur die "drwxr-xr-x"-Rechte an, die aber schon seit vielen Jahren nicht mehr alleine darüber entscheiden, wer Schreibrecht hat.
 

Mi_Ka

Idared
Registriert
10.11.16
Beiträge
26
Moin Marcel, wenn ein User "mitarbeiter1" der Gruppe "xxxx" auf dem Server einen Ordner "abcd" anlegt, dann ist der Zugriff wie folgt geregelt: Ordnername "abcd", Owner "mitarbeiter1", Group "xxxx" mit drwxr-xr-x (so nicht manuell eingegriffen wird). Nun greift "mitarbeiter2" aus der Gruppe "xxxx" auf diesen Ordner "abcd" zu und will für seinen Kollegin/en "mitarbeiter1" eine Datei zur Weiterbe-/verarbeitung dort ablegen. No go ... Zugriff verweigert. Das ist mein konkretes Problem ... es sei denn, ich greife manuell ein.

Und was ich völlig krank finde, ist der Umstand, wenn mitarbeiter1 (als Gruppenmitglied von "xxxx") einen Ordner auf einem Server-Volumen anlegt, dann ist direkt am Server via Finder und auch über Terminal dieser Ordner auch "mitarbeiter1" und "xxxx" zugeordnet ... allerdings leider mit drwxr-xr-x. Von dem Arbeitsplatz, an welchem "mitarbeiter1" diesen Ordner auf dem Server angelegt hat, zeigt aber "Informationen" über diesen Ordner als Owner "_unknown" und als Group "staff" ... will heißen, dass der Abgleich bezüglich Owner und Group zwischen Arbeitsplatz OSXClient 10.6.8 und OSXServer 10.11.6 weder beim Erstellen noch beim Aufrufen schon nicht funktioniert ... Frage ist nur, warum ?
 
Zuletzt bearbeitet:

Marcel Bresink

Hadelner Sommerprinz
Registriert
28.05.04
Beiträge
8.541
Du brauchst das Problem nicht immer und immer wieder neu zu beschreiben. Wir haben das Problem verstanden, aber Du verstehst offenbar die Lösung nicht.

dann ist der Zugriff wie folgt geregelt: Ordnername "abcd", Owner "mitarbeiter1", Group "xxxx"

Das regelt nur einen Teil des Zugriffs, der in Deiner Konfiguration aber keine Rolle spielen sollte. Es ist egal, wer der Eigentümer und wer der Gruppeneigentümer des Ordners ist. Andere Gruppen können trotzdem Schreibrecht haben.

allerdings leider mit drwxr-xr-x

Auch das spielt keine Rolle. Diese Einstellung ist bedeutungslos, wenn sie durch eine passende Zugriffssteuerungsliste überschrieben wird.
 

Mi_Ka

Idared
Registriert
10.11.16
Beiträge
26
Die Dinge aus #31 mache ich am Wochenende, wenn keine Produktion läuft.

Ich habe für alle und jeden "Lesen & Schreiben" aktiviert ... schon vor Tagen und gerade noch mal kontrolliert.
 
Zuletzt bearbeitet von einem Moderator:

u0679

Moderator
AT Moderation
Registriert
09.11.12
Beiträge
7.332
@Mi_Ka, bitte sei so gut und fasse Post`s zusammen, anstatt sie im Minutentakt hintereinander zu posten. Danke Dir.