10.11.6 Server - Gruppenrechte-Problem

[Mi_Ka]

Hallo,

ich habe hier ein Gruppenrechte-Problem:

In der Gruppe "abcd" befinden sich die User (alle unter 10.6.8 ! ... will heißen, Zugriff erfolgt dann über AFP)
xyz1
xyz2
xyz3

Wenn jetzt User xyz1 ein Verzeichnis anlegt, dann sieht das bzgl. der Rechte so aus: drwxr-xr-x.

Somit haben xyz2 und xyz3 zwar Leserechte, aber können nichts verändern oder löschen.

Tante Google schmeißt zwar einiges raus ... aber nichts hat geholfen.

Workaround ist natürlich, dass der User xyz1 über die Finder-Info für das Verzeichnis "abcd" alles auf "Lesen & Schreiben" setzt ... das ist aber unschön und nicht so dauerhaft gewollt.

Am Arbeitsplatz von xyz1 steht der User auf "_unknown" mit "Lesen & Schreiben", die Gruppe auf "staff" sowie "everyone" mit "Nur Lesen".

Am 10.11.6 Server ergibt die Finder-Info allerdings sehr interessante Infos: Als erstes steht die Gruppe "abcd" auf "Eigene", dann folgt der User "xyz1" mit "Schreiben & Lesen", gefolgt von Gruppe "abcd" sowie "everyone" mit "Nur Lesen".

Ein Kollege meinte, das wäre ein Bug zwischen SMB und AFP in El Capitan. Ich finde dazu aber nichts.

Hat jemand eine Idee ?

Gruß Mi_Ka

 

[Marcel Bresink]

Somit haben xyz2 und xyz3 zwar Leserechte, aber können nichts verändern oder löschen.

Das ist der gewünschte Standardfall. Ohne diese Sicherheitsfunktion wäre es unmöglich, den Server in Umgebungen mit "nicht-kooperativen Nutzern", z.B. einer Schule, einzusetzen.

Wenn das Standardverhalten nicht gewünscht ist, müssen die Berechtigungen anders konfiguriert werden:

1) Problem 1 ist, dass offenbar keine netzweiten Benutzer-Accounts (über Open Directory) verwendet werden, sondern lokale Accounts auf dem Server. Jeder Rechner verwendet damit Accounts, die den anderen Rechnern jeweils unbekannt sind (selbst wenn sie "zufällig" den gleichen Namen tragen). Für gemeinsame Nutzung von Dateien ist das keine günstige Voraussetzung.
2) Die Gruppenberechtigungen des freigegebenen Ordners müssen umgestellt werden. Für eine Gruppe, in der die entsprechenden Benutzer Mitglied sind, muss ein Zugriffssteuerungseintrag (ACE) auf dem Ordner angelegt werden. In dem ACE müssen alle vier Optionen für Vererbung (auf diesen Ordner, auf Unterordner, auf Dateien, auf alle Ebenen) eingeschaltet werden. Damit die Änderung auch auf die bereits bestehenden Dateien wirksam wird, muss die Zugriffssteuerungsliste des Ordners danach noch auf alle enthaltenen Objekte propagiert werden.

Ein Kollege meinte, das wäre ein Bug zwischen SMB und AFP in El Capitan.

Nein. SMB kommt hier ja auch nirgendwo zum Einsatz.

 

[Mi_Ka]

Hallo Marcel,

im Apple Support hab' ich diese Einstellungsmöglichkeit (Zugriffssteuerungseintrag (ACE) auf dem Ordner angelegt werden) im Server-Admin nur für den 10.6-Server gefunden.

Wo finde ich das denn in El Capitan Server ?

Danke und Gruß Mi_Ka

 

[Marcel Bresink]

Gemeint ist wahrscheinlich macOS Server 5?

Dort unter Name des Servers > "Speicher" > Ordner auswählen > Zahnradmenü öffnen > Zugriffsrechte bearbeiten > +-Knopf > Aufdeckungspfeil des neuen Rechteeintrags öffnen.

Das nachträgliche Propagieren von Rechten nach unten in die Hierarchie geht mit Zahnradmenü > "Zugriffsrechte übertragen".

 

[Mi_Ka]

Mille Gracie

 

[Mi_Ka]

Also so funktioniert es hier leider nicht. In diesem kleinen Unternehmen gibt es noch einen Verwaltungsserver, welcher noch unter 10.5.8 Server mit Open Directory auf einem G5 läuft. Zwischen 10.11.6 OD und 10.5.8 OD kann kein Replik wegen der unterschiedlichen OSX gemacht werden ... ich habe irgendwo gelesen, dass auch zwei oder mehrere Master in einem lokalen Netzwerk laufen dürfen. Das geht in diesem Fall aber nicht, weil dann die Verwaltungsclients die Verbindung zur Verwaltungsdatenbank verlieren, obwohl es keine User-Namen Überschneidungen zwischen 10.11.6 OD und 10.5.8 OD gibt ... Fakt also: 10.11.6 OD abschalten, damit die Verwaltung weiterläuft.

Jetzt stehe ich auf dem Schlauch wegen der Gruppenrechte unter 10.11.6, welche nach obiger Vorgehensweise leider nicht funktionieren. Es gibt keinerlei Fehlermeldung in den Logs.

 

[Mi_Ka]

Update: Durch einen Kernel-Panic-Fehler am 10.11.6 Server (vermutlich Überhitzung durch ausgefallene Klimaanlageim Serverraum) wurde alles neugestartet. Jetzt funktionieren beide OD Systeme als Master auch gegen einander ohne die Verwaltungssoftware-Zugriffe gegen den 10.5.8 zu stören.

Ein User "mitarbeiter" als 10.6.8-Client meldet sich am 10.11.6 OD Server an ... ist im Server-Admin auch als angemeldet zu sehen und legt ein Verzeichnis an: Leider wieder drwxr-xr-x.

Anm: Alle User wurden heute in Frühe gelöscht und über den Server-Admin neu anlegt.

 

[Mi_Ka]

Hallo nochmal,

wenn ich via Terminal als admin direkt auf dem Server ein Verzeichnis xyz erstelle, dann sind die Zugriffsrechte wie gewünscht drwxrwxr-x. So ich von einem 10.6.8-Client via User admin und Finder auf einem Netzwerk-Laufwerk die gleiche Aktion ausführe ist das Ergebnis drwxr-xr-x Irgendeine Idee ?

Gruß Mi_Ka

 

[Mi_Ka]

Wenn ich via Terminal und ssh remote als admin auf den Server draufgehe, dann hab' ich bei mkdir xyz den gleichen Effekt drwxr-xr-x. Mache ich das Gleiche als admin direkt am MacOSX-Server via Terminal dann ist das Ergebnis drwxrwxr-x.

 

[Mi_Ka]

Erstes Verzeichnis von MacOSX-Client 10.6.8.
Zweites Verzeichnis direkt am MacOSX-Server 10.11.6.

 

[Marcel Bresink]

wenn ich via Terminal als admin direkt auf dem Server ein Verzeichnis xyz erstelle, dann sind die Zugriffsrechte wie gewünscht drwxrwxr-x. So ich von einem 10.6.8-Client via User admin und Finder auf einem Netzwerk-Laufwerk die gleiche Aktion ausführe ist das Ergebnis drwxr-xr-x

Das hängt von drei Faktoren ab, nämlich
1) dem Programm, das das Objekt anlegt,
2) den umask-Einstellungen des Benutzers, der dieses Programm aufruft,
3) bei File-Server-Zugriff dem Netzwerkprotokoll, das für den Zugriff genutzt wird.

Um bei Direktzugriff und AFP (sowie aktuellen Versionen von SMB) solche Unsicherheiten auszuschließen, muss man zwingend Zugriffssteuerungslisten verwenden. Die POSIX-Rechte sind deshalb der falsche Ort, solche Dinge nachzuprüfen. Auch wenn das zweite w fehlt, muss das nicht bedeuten, dass die Benutzergruppe kein Schreibrecht hat. Das könnte man erst mit "ls -le" sehen.

 

[Mi_Ka]

1. Finder entfernt MacOSX-Client 10.6.8 wie lokal MacOSX-Server 10.11.6
2. umask 0022 <- da ist der Fehler ... aber die /etc/launchd-user.conf gibt eigentlich "umask 002" vor ... scheint aber nicht zu greifen.
3. AFP ... unter 10.4- und 10.5-Server hat alles funktioniert ... erst durch den Hardware-Ausfall und den Umzug auf einen neuen Server mit 10.11 kam das Problem hoch

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.

 

[Mi_Ka]

Via Termal remote-login von einem entfernten MacOSX-Client 10.6.8 erstelltes Verzeichnis testxyz mit mkdir
drwxr-xr-x+ 2 mac xxxx 68 Nov 18 09:25 testxyz
0: group:staff inherited allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit

Via Terminal direkt am MacOSX-Server 10.11.6 erstelltes Verzeichnis testzxy mit mkdir
drwxrwxr-x+ 2 mac xxxx 68 Nov 18 09:27 testzxy
0: group:staff inherited allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit

Also ich sehe da keinen Unterschied ... Fakt bleibt aber, dass aus der Gruppe xxxx kein MacOSX-Client 10.6.8 Gruppenrechte hat ... kann also nicht verändern, löschen etc. ... sondern nur der User, welcher das angelegt hat.

 

[Mi_Ka]

sudo launchctl config user umask 002
sudo launchctl config system umask 002

wurden natürlich auch schon gleich zu Anfang gemacht.

 

[Marcel Bresink]

Fakt bleibt aber, dass aus der Gruppe xxxx kein MacOSX-Client 10.6.8 Gruppenrechte hat

Ja, weil die Zugriffssteuerungsliste fälschlicherweise für die Gruppe "staff" angelegt wurde statt für die Gruppe "xxxx".

 

[Mi_Ka]

Moin Marcel, wie kann das sein, wenn auf dem MacOSX-Server UID und GID richtig sind, aber andererseits die Rechte drwxr-xr-x sind. Interessant ist allerdings, dass man über den MacOS-Client 10.6.8 via Informationen für diesen neu angelegten Ordner als uid "_unknown" und guid "staff" ist.

 

[Marcel Bresink]

Die Frage habe ich nicht verstanden. Für eine Zugriffssteuerungsliste spielen Eigentümer und POSIX-Rechte keine Rolle.

 

[Mi_Ka]

Moin, wenn ich mich direkt am MacOSX-10.11.6-Server als "Mitarbeiter" einlogge und ein Verzeichnis im Terminal via mkdir erstelle, dann sind die die Zugriffsrechte wie gewünscht drwxrwxr-x. 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.

 

[u0679]

10.6.8-MacOSX-Client

gibt es denn einen Grund, die Clients nicht hochzuziehen?

 

[Mi_Ka]

Ja ... veraltete Hardware ... mehr als 10.6.8 geht nicht ... ältere iMacs ... die können net mehr hoch.