Grundsatzfragen zu Samba 4

[MSfree]

Der Server muss doch wissen, wer welchen Zugriff auf die Dateien hat?

Nein, genau das muß der Server nicht wissen.

Spielen die Gruppen und Dateirechte auf dem Server also gar keine Rolle?

Gruppen-ID, Benutzer-ID und Dateirechte sind nur Dateiattribute, die auf dem Dateisystem gespeichert werden, wobei Gruppen-ID und Benutzer-ID nur in Form einer Zahl gespeichert werden.

Die müssen doch irgendwie abgeglichen werden?

Natürlich, aber das macht im Falle von NFS der Client

Nehmen wir an ich hab auf dem Client einen Benutzer. Woher weiss der Server nun, was der Benutzer darf und was nicht, wenn nicht vorher auf dem Server festgelegt?

Der Server weiß es nicht und muß es auch nicht wissen.

Dein Benutzer fragt schließlich den Linuxkernel auf dem Client, auf eine Bestimmte Datei zugreifen zu wollen. Der Clientkernel fragt nun den Server, ob die Datei existiert, welche Benutzernummer und Gruppennummer der Datei zugeordnet ist und wie die Dateirechte aussehen. Dann entscheidet der Clientkernel, ob Zugriff gestattet wird.

Selbst wenn der Benutzer auf dem Server nicht angelegt wird, so muss doch auf dem Serversystem zb. durch Gruppen festgelegt werden, wer auf welche Dateien zugreifen darf?

Nein. Das handhabt alles der Linuxkernel des Clients.

Wenn die z.B als Hugo eine Datei anlegen willst, dann schaut der Clientkernel erstmal, wie die Benutzernummer und Gruppennummer lautet, die Hugo zugeordnet ist, Dieses findet über die Dateien /etc/passwd und /etc/group auf dem Client statt. Dies ergibt beispielsweise Benutzer=1001, Gruppe=2000. Der Client entscheidet dann, ob der Benutzer 1001/2000 auf das Zielverzeichnis schreiben darf, also Schreibrechte für 1001/2000 aufweist. Erst, wenn das geklärt ist, sagt der Clientkernel dem NFS-Server, daß eine Datei auf den Zielverzeichnis für den Nutzer 1001/2000 angelegt werden soll, z.B. mit den Rechten 600.

Wenn jetzt Otto, der z.B. Benutzer 1002, Gruppe 3000 ist, die Datei lesen wil, die Hugo (1001/2000) angelegt hat, wird vom Clientkernel geprüft, ob der Nutzer 1002/3000 auf die Datei zugreifen darf, die 1001/2000 gehört und nur Lesen für 1001/2000 gewährt. Wenn, wie in diesem Fall keine Berechtigung besteht, dann sagt der Clientkernel "nein".

Daß der Benutzer 1001/2000 Hugo auf dem Client heißt, muß der Server nicht wissen, in /etc/passwd des Servers muß Hugo also auch nicht eingetragen sein. Selbes gilt für Otto.

[Trollkirsche]

Der Server muss doch wissen, wer welchen Zugriff auf die Dateien hat?

Nein, genau das muß der Server nicht wissen.

Spielen die Gruppen und Dateirechte auf dem Server also gar keine Rolle?

Gruppen-ID, Benutzer-ID und Dateirechte sind nur Dateiattribute, die auf dem Dateisystem gespeichert werden, wobei Gruppen-ID und Benutzer-ID nur in Form einer Zahl gespeichert werden.

Die müssen doch irgendwie abgeglichen werden?

Natürlich, aber das macht im Falle von NFS der Client

Nehmen wir an ich hab auf dem Client einen Benutzer. Woher weiss der Server nun, was der Benutzer darf und was nicht, wenn nicht vorher auf dem Server festgelegt?

Der Server weiß es nicht und muß es auch nicht wissen.

Dein Benutzer fragt schließlich den Linuxkernel auf dem Client, auf eine Bestimmte Datei zugreifen zu wollen. Der Clientkernel fragt nun den Server, ob die Datei existiert, welche Benutzernummer und Gruppennummer der Datei zugeordnet ist und wie die Dateirechte aussehen. Dann entscheidet der Clientkernel, ob Zugriff gestattet wird.

Selbst wenn der Benutzer auf dem Server nicht angelegt wird, so muss doch auf dem Serversystem zb. durch Gruppen festgelegt werden, wer auf welche Dateien zugreifen darf?

Nein. Das handhabt alles der Linuxkernel des Clients.

Wenn die z.B als Hugo eine Datei anlegen willst, dann schaut der Clientkernel erstmal, wie die Benutzernummer und Gruppennummer lautet, die Hugo zugeordnet ist, Dieses findet über die Dateien /etc/passwd und /etc/group auf dem Client statt. Dies ergibt beispielsweise Benutzer=1001, Gruppe=2000. Der Client entscheidet dann, ob der Benutzer 1001/2000 auf das Zielverzeichnis schreiben darf, also Schreibrechte für 1001/2000 aufweist. Erst, wenn das geklärt ist, sagt der Clientkernel dem NFS-Server, daß eine Datei auf den Zielverzeichnis für den Nutzer 1001/2000 angelegt werden soll, z.B. mit den Rechten 600.

Wenn jetzt Otto, der z.B. Benutzer 1002, Gruppe 3000 ist, die Datei lesen wil, die Hugo (1001/2000) angelegt hat, wird vom Clientkernel geprüft, ob der Nutzer 1002/3000 auf die Datei zugreifen darf, die 1001/2000 gehört und nur Lesen für 1001/2000 gewährt. Wenn, wie in diesem Fall keine Berechtigung besteht, dann sagt der Clientkernel "nein".

Daß der Benutzer 1001/2000 Hugo auf dem Client heißt, muß der Server nicht wissen, in /etc/passwd des Servers muß Hugo also auch nicht eingetragen sein. Selbes gilt für Otto.

Auf der Seite:
https://linuxwiki.de/NFS
steht folgendes:
Die Benutzerkennungen auf Server und Client müssen für die korrekte Funktion übereinstimmen.

Mir ist schon klar das intern in Linux Systemen die uid und gid wichtig ist und nicht der Name selbst.

Damit der Benutzer von einem Client aus auf einen NFS Ordner zugreifen darf, muss der NFS Ordner diesselbe gid besitzen, wie die gid des Benutzers auf dem Client? Ist das korrekt?

Weiter steht:
Benutzerkennungen auf Server und Client müssen übereinstimmen also die Gruppen- und Passwortdatei:

/etc/group users100:mein-Loginname (Beispiel users100:detlef,tobias,sandra)

/etc/passwd mein-Loginname1000:1000:mein-Loginname,,,:/home/mein-Loginname:/bin/bash

muss auf Server und Client identisch sein.

So wie ich das verstehe müssen also auf beiden Systemen beide Male die gleichen benutzer wie auch user definiert werden, damit der Abgleich vonstatten gehen kann. Richtig?

[TomL]

Hm, irgendwie steh ich auf dem Schlauch.

Ich momentan auch..... wegen...

Ich habe Windows Dual Boot fürs Gaming im LAN, zwei PCs. Aus diesem Grunde kommt nur Samba in Frage, da auf dem NAS auch GOG Spiele zu finden sind.

Seit wann geht es denn jetzt um NFS? Kann Windows jetzt auch NFS?

[TomL]

Nein. Das handhabt alles der Linuxkernel des Clients.

Das heisst, anstatt auf einem Samba-Server einmalig zentral die Rechte via Samba zu setzen zu pflegen, muss ich dass dann auf jedem Client machen... also überall Gruppen, User und spezielle Berechtigungen einrichten? Und das dann bei jeder Änderunge (sicher, die sind selten) erneut ausrollen? Und das soll einfacher sein?

Dann vergleicht der Client die Benutzernummer des eingelogten Benutzers mit der Benutzernummer der angefragten Datei und entscheidet, ob Zugriff gewährt wird oder oder.

Wie soll das funktionieren? Auf meinem PC habe ich die UID 1000, im Büro 1006, auf dem Laptop meines Sohnes 1002, auf dem Server 1008, usw... was für eine Nummer soll denn da verglichen werden? Wie kriegt man denn UIDs synchron, wenn Geräte im Laufe der Zeit ausgetauscht werden und neue Geräte reinkommen. Muss ich dann erst 6 Dummy-User anlegen, damit ich die UID 1006 bekomme? Nee, das krieg ich grad gar nicht auffe Reihe.

Mit Samba muss ich mich da jedenfalls nicht drum kümmern und krieg user-bezogene Rechte auf Samba-Files ganz einfach..... losgelöst von unterschiedlichen Client-UIDs

[Trollkirsche]

Nein. Das handhabt alles der Linuxkernel des Clients.

Das heisst, anstatt auf einem Samba-Server einmalig zentral die Rechte via Samba zu setzen zu pflegen, muss ich dass dann auf jedem Client machen... also überall Gruppen, User und spezielle Berechtigungen einrichten? Und das dann bei jeder Änderunge (sicher, die sind selten) erneut ausrollen? Und das soll einfacher sein?

Dann vergleicht der Client die Benutzernummer des eingelogten Benutzers mit der Benutzernummer der angefragten Datei und entscheidet, ob Zugriff gewährt wird oder oder.

Wie soll das funktionieren? Auf meinem PC habe ich die UID 1000, im Büro 1006, auf dem Laptop meines Sohnes 1002, auf dem Server 1008, usw... was für eine Nummer soll denn da verglichen werden? Wie kriegt man denn UIDs synchron, wenn Geräte im Laufe der Zeit ausgetauscht werden und neue Geräte reinkommen. Muss ich dann erst 6 Dummy-User anlegen, damit ich die UID 1006 bekomme? Nee, das krieg ich grad gar nicht auffe Reihe.

Mit Samba muss ich mich da jedenfalls nicht drum kümmern und krieg user-bezogene Rechte auf Samba-Files ganz einfach..... losgelöst von unterschiedlichen Client-UIDs

Wir sind im Laufe der Diskussion auf NFS geswitcht, da mir von MSFree angeraten wurde, die Linux Shares unter NFS zu betreiben und die Samba Shares read-only für Windows

Daher wohl die Konfusion.

[MSfree]

Auf der Seite:
https://linuxwiki.de/NFS
steht folgendes:
Die Benutzerkennungen auf Server und Client müssen für die korrekte Funktion übereinstimmen.

Die Benutzerkennung und Group-ID sind Zahlen.

Damit der Benutzer von einem Client aus auf einen NFS Ordner zugreifen darf, muss der NFS Ordner diesselbe gid besitzen, wie die gid des Benutzers auf dem Client? Ist das korrekt?

Richtig.

Benutzerkennungen auf Server und Client müssen übereinstimmen also die Gruppen- und Passwortdatei:

/etc/group users100:mein-Loginname (Beispiel users100:detlef,tobias,sandra)

/etc/passwd mein-Loginname1000:1000:mein-Loginname,,,:/home/mein-Loginname:/bin/bash

Falsch.
Auf dem Server wird überhaupt keine User-ID und Group-ID Eintrag benötigt.

So wie ich das verstehe müssen also auf beiden Systemen beide Male die gleichen benutzer wie auch user definiert werden, damit der Abgleich vonstatten gehen kann. Richtig?

Falsch.

[MSfree]

Wie soll das funktionieren? Auf meinem PC habe ich die UID 1000, im Büro 1006, auf dem Laptop meines Sohnes 1002, auf dem Server 1008, usw... was für eine Nummer soll denn da verglichen werden?

Du sollst auf jedem Client deinen Benutzer mit der selben Benutzernummer und Gruppennummer einrichten.

Wie kriegt man denn UIDs synchron, wenn Geräte im Laufe der Zeit ausgetauscht werden und neue Geräte reinkommen. Muss ich dann erst 6 Dummy-User anlegen, damit ich die UID 1006 bekomme? Nee, das krieg ich grad gar nicht auffe Reihe.

Dem Befehl adduser (siehe man adduser) kann die User-ID und die Group-ID mitgegeben werden:

z.B. mit

Code: Alles auswählen

adduser --home /home/hugo --shell /bin/bash --uid 4711 --gid 4242 hugo

Letztlich sind /etc/passwd und /etc/group nur ASCII-Dateien, in denen man die IDs auch editieren kann. Bereits exisierende Dateien muß man dann unter Umständen mit chown anpassen. OK, nachträglich ist das lästig, aber nur einmalig nötig.

Wenn man es von Anfang an so handhabt, ist es kein Problem.

Mit Samba muss ich mich da jedenfalls nicht drum kümmern und krieg user-bezogene Rechte auf Samba-Files ganz einfach..... losgelöst von unterschiedlichen Client-UIDs

Das Problem ist, daß Samba und NFS eben so völlig anders konzipiert sind. Hat man das eine verstanden, erscheint einem das andere unlogisch, kompliziert und komisch. Vor allem, wenn man von Windows kommt, erscheint einem NFS erstmal unlogisch, obwohl das eigentlich sehr viel einfacher aufgebaut und handzuhaben ist.

NFS existiert nun schon über 30 Jahre und war von vorn herein auf Multiuser ausgelegt. Samba stammt aus Windows 3.0, das ein Einzelplatzsystem für einen einzelnen Benutzer und einem einzigen laufenden Programm ausgelegt war. Das Konzept, daß sich ein Rechner an einem Netz anmeldet, stammt noch aus dieser Zeit. Und da die Systeme nur Einplatzsysteme waren, war Benutzerlogin und Rechneranmeldung das Selbe. Multiuser und Multitasking wurder erst viel Später mit WinNT aufgestülpt. Hier liegt dann auch der Grund, warum Samba so völlig anders funktionieren muß.

Aber so ganz nebenbei gibt es natürlich unter Linux auch Möglichkeiten, Benutzer zentral zu verwalten, unter Verzicht von /etc/passwd und /etc/group. Das erste System hieß Yellow Pages (yp), heute nimmt man dafür meist LDAP und löst damit das Problem, daß die User-IDs sich von Rechner zu Rechner unterscheiden könnten.

[Trollkirsche]

Auf der Seite:
https://linuxwiki.de/NFS
steht folgendes:
Die Benutzerkennungen auf Server und Client müssen für die korrekte Funktion übereinstimmen.

Die Benutzerkennung und Group-ID sind Zahlen.

Damit der Benutzer von einem Client aus auf einen NFS Ordner zugreifen darf, muss der NFS Ordner diesselbe gid besitzen, wie die gid des Benutzers auf dem Client? Ist das korrekt?

Richtig.

Benutzerkennungen auf Server und Client müssen übereinstimmen also die Gruppen- und Passwortdatei:

/etc/group users100:mein-Loginname (Beispiel users100:detlef,tobias,sandra)

/etc/passwd mein-Loginname1000:1000:mein-Loginname,,,:/home/mein-Loginname:/bin/bash

Falsch.
Auf dem Server wird überhaupt keine User-ID und Group-ID Eintrag benötigt.

So wie ich das verstehe müssen also auf beiden Systemen beide Male die gleichen benutzer wie auch user definiert werden, damit der Abgleich vonstatten gehen kann. Richtig?

Falsch.

Vorweg zur Vermeidung von Konfusion : Ich beziehe mich ausschliesslich auf NFS, nicht Samba.

Du sagst, auf dem Server würde keine User ID und Group ID benötigt. Gleichzeitig bestätigst du, dass der Benutzer eines Clients, der auf einen NFS Ordner zugreifen will, die gleiche gid oder uid haben muss, wie der Ordner.

Wie lässt sich das vereinbaren? Der Server exportiert einen Ordner. Dieser Ordner wiederum hat bestimmte Rechte. Wenn nun diese Rechte jedoch nicht mit der uid oder gid des Benutzers des Clients übereinstimmen, dann wird doch der Zugriff verwehrt? Also muss doch der Ordner auf dem Server erstmal eine uid oder gid zugewiesen bekommen, der es dem Benutzer erlaubt, auf den NFS Ordner zuzugreifen?

Tut mir leid, aber ich hab da echt einen Knoten...

[TomL]

Das Problem ist, daß Samba und NFS eben so völlig anders konzipiert sind. Hat man das eine verstanden, erscheint einem das andere unlogisch, kompliziert und komisch. Vor allem, wenn man von Windows kommt, erscheint einem NFS erstmal unlogisch, obwohl das eigentlich sehr viel einfacher aufgebaut und handzuhaben ist.

Nein, kein Problem, ist mir nicht unlogisch. Ich arbeite seit fast 40 Jahren mit Datenbanken und bestimmt seit 30 Jahren mit Rechtemanagement. Ich habe von Anfang an verstanden, wie das gehen würde, wenn man das so einrichtet... ich betone "wenn"... aber ohne ein Tool für eine zentrale Benutzerverwaltung halte ich das für unpraktikabel. Allerdings da stimme ich Dir zu, LDAP wäre vielleicht eine Lösung. Ich strebe aber eine Lösung an, die minimalistisch im Setup ist, aber (für uns) maximal im Ergebnis ist. Die Clients sollen weitestgehend Standard-Setup sein, ohne großes individuelles Customizing. Ich will noch nicht mal über UIDs nachdenken, sondern machs in der Reihenfolge, wie es mir in den Sinn kommt oder bei Bedarf. Beim Rechner-Setup kopiere ich schnell ein paar Service-Units, 2 Scripte und das wars.... den Rest macht der Sambaserver. Und weil auf dem Client per Eventhandler nach dem User-Login mit der Samba-Anmeldung des User gemountet wird, kann der User auch nur mit seinen Rechten (die er auf dem Server hat) arbeiten.

[MSfree]

Du sagst, auf dem Server würde keine User ID und Group ID benötigt. Gleichzeitig bestätigst du, dass der Benutzer eines Clients, der auf einen NFS Ordner zugreifen will, die gleiche gid oder uid haben muss, wie der Ordner.

Wie lässt sich das vereinbaren?

Der exportierte Ordner sollte natürlich Schreib und Leserechte für alle haben, also 777-Rechte haben. Legt ein Benutzer nun einen Ordner an, so kann er das dort tun, weil die oberste Ebene eben für jeden beschreibbar ist. Die vom Benutzer neu angelegte Ordner wird ganz einfach mit der User-ID, der Gruppen-ID und den Zugriffsrechten, die per umask definiert sind, auf dem Server angelegt. In dem Unterorner hat nun nur noch der Benutzer alle Rechte, der den Ordner angelegt hat. Der Server braucht dazu keinen Eintrag in seiner passwd/group.

[MSfree]

aber ohne ein Tool für eine zentrale Benutzerverwaltung halte ich das für unpraktikabel.

Naja, es kommt immer auf die Größenordnung an. Wenn ich 3-4 Rechner insgesammt habe, die von 4-6 Leuten benutz werden, dann ist eine zentrale Benutzerverwaltung vielleicht doch ein wenig mit Kanonen auf Spatzen geschossen.

Wenn ich das für die Mitarbeiter eines großen Konzerns mit mehreren 1000 Mitarbeitern organisieren muß, nehme ich eine zentrale Verwaltung.

Das ist so wie mit der /etc/hosts Datei. Ich kann das IP-Adressproblem zentral mit einem DHCP- und einem Nameserver lösen oder dezentral mit Einträgen auf jedem Rechner in der /etc/hosts. Selbst hier im Forum schwören immer noch viele auf die hosts-Methode, ich nutze seit 25 Jahren eine Kombination aus DHCP und DNS, weil es mir die Arbeit komplett abnimmt.

.... den Rest macht der Sambaserver

Nunja, je nachdem, wie man den einrichtet, führt der Sambaserver bei unbekannten Benutzern ein adduser aus und legt ihn so in der /etc/passwd /etc/group an. Das ist aber nicht das Defaultverhalten.

[TomL]

Nunja, je nachdem, wie man den einrichtet, führt der Sambaserver bei unbekannten Benutzern ein adduser aus und legt ihn so in der /etc/passwd /etc/group an.

Na sowas gibts hier nicht. Jeder Client hat mindestens 1 User, mache Clients haben mehrere User. Der Server kennt als einzige Maschine alle User, soll heißen, dort sind sie Linuxmäßig und mit Samba-pwd angelegt. Was die User dürfen steht zentral in der smb.conf.... und nur da.... auf den Client-PCs muss ich nix dafür an rechten einstellen.

[Trollkirsche]

Du sagst, auf dem Server würde keine User ID und Group ID benötigt. Gleichzeitig bestätigst du, dass der Benutzer eines Clients, der auf einen NFS Ordner zugreifen will, die gleiche gid oder uid haben muss, wie der Ordner.

Wie lässt sich das vereinbaren?

Der exportierte Ordner sollte natürlich Schreib und Leserechte für alle haben, also 777-Rechte haben. Legt ein Benutzer nun einen Ordner an, so kann er das dort tun, weil die oberste Ebene eben für jeden beschreibbar ist. Die vom Benutzer neu angelegte Ordner wird ganz einfach mit der User-ID, der Gruppen-ID und den Zugriffsrechten, die per umask definiert sind, auf dem Server angelegt. In dem Unterorner hat nun nur noch der Benutzer alle Rechte, der den Ordner angelegt hat. Der Server braucht dazu keinen Eintrag in seiner passwd/group.

Okay vielleicht fängt dort bei mir der ärger schon an. Ich exportiere zwar den Ordner per rw rechte und binde sie per /etc/fstab auch wieder per rw ein. Mein Ziel war es jedoch, nicht alle im obersten Verzeichnis schreiben zu lassen, sondern nur ausgewählte benutzer, sollen dateien editieren, löschen usw. haben.

[Trollkirsche]

Frage : Ist das exportierte Verzeichnis in jedem Falle für alle beschreibbar, wenn es in der fstab per rw gemountet wurde?
Gibt es keine Möglichkeit, den Zugriff auf den export für andere Nutzer desselben Clients zu verhindern?

[Trollkirsche]

Ok ich hab wohl verstanden, warum ich immer noch Zugriff auf den Server hatte, obwohl der exportierte Ordner eigentlich die Zugriffe hätte einschränken sollen.

Testweise habe ich auf dem Client den Benutzer aus einer Gruppe genommen, zu der er vorher hinzugefügt war. Da ich den PC nicht neu gestartet habe, hat sich der User wohl immer noch in der Gruppe hinzugefügt gesehen.

Man muss sich also zumindest an und abmelden, wenn man die Information, zu welcher Gruppe ein Benutzer hinzugefügt ist, aktualisieren will.

Weitere Frage : Bietet NFS nicht auch ein hohes Missbrauchspotential? Nehmen wir an, ich ändere die UID eines Benutzers auf dem Client zu einer UID eines vom Server freigegebenen Ordners.. damit hätte ich doch vollen Zugriff auf das Share?

Wenn das stimmt, dann muss man bei NFS immer davon ausgehen, dass alle Gastsysteme, die auf den Server zugreifen, vertrauenswürdig sind. Ist im lokalen Netz ein Nutzer mit schlechten Absichten unterwegs, dann kann er dadurch auch Zugriff auf Shares des Servers erlangen, zu denen er eigentlich keinen Zugriff erhalten sollte. Dies macht den Einsatz von NFS in grossen Unternehmensnetzwerken nur möglich, wenn die Authentfikation zentral gesteuert wird. (Mal abgesehen vom Verwaltungsaufwand )

Zudem habe ich gelesen, dass Daten per NFS unverschlüsselt übertragen werden. Ist das noch aktuell? Das wäre sehr schlecht, wie ich finde.

[MSfree]

Bietet NFS nicht auch ein hohes Missbrauchspotential? Nehmen wir an, ich ändere die UID eines Benutzers auf dem Client zu einer UID eines vom Server freigegebenen Ordners.. damit hätte ich doch vollen Zugriff auf das Share?

Das ist schon richtig.

Wenn das stimmt, dann muss man bei NFS immer davon ausgehen, dass alle Gastsysteme, die auf den Server zugreifen, vertrauenswürdig sind.

Auch das ist richtig.

Auf der anderen Seite, was haben Gäste auf deinem NFS zu suchen? Dem Server kannst du in der /etc/exports ja eintragen, welchen Rechnern er vertrauen soll. Schau dir mal die Beispiele an, die man exports liefert.

Eine Freigabe nach dem Schema:

Code: Alles auswählen

/pub   *(rw)

Ist für jeden (Gast)rechner schreib- und lesbar. Damit hättest du dann das von dir genannte Vetrauensproblem.

Eine Freigabe nachj dem Schema:

Code: Alles auswählen

/pub    himbeere(ro,insecure)

Würde dem Rechner "himbeere" (das ist mein Raspberry) nur Leserechte einräumen und andere dürten überhaupt nicht zugreifen.

Zudem habe ich gelesen, dass Daten per NFS unverschlüsselt übertragen werden. Ist das noch aktuell?

Das gilt zumindest bis zur Version NFS3. Samba verschlüsselt ebenfalls nicht, ausser der Übertragung der Benutzernamen und Paßwörter.

NFS4 kann komplett verschlüsseln, ist aber entsprechend umfangreicher zu konfigurieren.

[Trollkirsche]

Jetzt hab ichs eeeeendlich gecheckt Was eine Nacht drüber schlafen alles bewirken kann...

Bietet NFS nicht auch ein hohes Missbrauchspotential? Nehmen wir an, ich ändere die UID eines Benutzers auf dem Client zu einer UID eines vom Server freigegebenen Ordners.. damit hätte ich doch vollen Zugriff auf das Share?

Das ist schon richtig.

Ok. Zum normalen Gebrauch muss man daher beachten, dass jeder Benutzer eine eindeutige UID auf seinem Client aufweist,damit sich die User nicht in die Quere kommen.

Wenn das stimmt, dann muss man bei NFS immer davon ausgehen, dass alle Gastsysteme, die auf den Server zugreifen, vertrauenswürdig sind.

Auch das ist richtig.

Auf der anderen Seite, was haben Gäste auf deinem NFS zu suchen? Dem Server kannst du in der /etc/exports ja eintragen, welchen Rechnern er vertrauen soll. Schau dir mal die Beispiele an, die man exports liefert.

Ja stimmt schon. Genau aus dem Grunde habe ich eigentlich schon vorher in der /etc/exports Datei nicht den Zugriff vom ganzen Netz gewährt, sondern explizit jeden Host berechtigt. Also soweit mal kein Problem.

Eine Freigabe nach dem Schema:

Code: Alles auswählen

/pub   *(rw)

Ist für jeden (Gast)rechner schreib- und lesbar. Damit hättest du dann das von dir genannte Vetrauensproblem.

Eine Freigabe nachj dem Schema:

Code: Alles auswählen

/pub    himbeere(ro,insecure)

Würde dem Rechner "himbeere" (das ist mein Raspberry) nur Leserechte einräumen und andere dürten überhaupt nicht zugreifen.

Zudem habe ich gelesen, dass Daten per NFS unverschlüsselt übertragen werden. Ist das noch aktuell?

Das gilt zumindest bis zur Version NFS3. Samba verschlüsselt ebenfalls nicht, ausser der Übertragung der Benutzernamen und Paßwörter.

NFS4 kann komplett verschlüsseln, ist aber entsprechend umfangreicher zu konfigurieren.

Zumindest besteht die Möglichkeit der Verschlüsselung, wobei wie du sagst, den eigenen Hosts im Netzwerk eh schon vertraut werden sollte. Meine Frage zielte eher auf Unternehmensnetzwerke ab, da wäre eine Verschlüsselung wohl unumgänglich.

Sobald ich etwas Zeit habe, werde ich dies aus Lernzwecken mal implementieren. Zurzeit steht bei mir jedoch erst noch die Migration des Clients von stretch nach buster an, damit ich nfsv4 nutzen kann. Stretch stable erlaubt noch nicht die Nutzung von nfsv4.

Eine weitere Frage die ich noch hätte : Kann man ACLs mit NFS bedenkenlos einsetzen?

Eine andere, weitere Frage bezieht sich auf die öffnung von Ports auf dem Server. Muss ich, wenn ich NFSv4 zu gegebener Zeit einsetze, den Port 2049 öffnen, damit die Geräte miteinander kommunizieren können?

Sobald ich etwas Zeit habe, werde ich dies aus Lernzwecken mal implementieren. Zurzeit steht bei mir jedoch erst noch die Migration des Clients von stretch nach buster an, damit ich nfsv4 nutzen kann. Stretch stable erlaubt noch nicht die Nutzung von nfsv4.

Einen Beitrag hierzu habe ich in einer anderen Sektion bereits eröffnet und du hast ebenfalls ja schon darauf geantwortet.

Vielen Dank nochmal für den äusserst wichtigen Hinweis, dass die Rechte jeweils auf dem Client abgeklärt werden und nicht auf dem Server. Das war für das Verständnis äusserst wichtig.

Ihr alle hier seid mir eine unschätzbar grosse Hilfe. Es ist das, was die Linux Community so einmalig macht und weswegen ich glücklich bin, Debian als System einzusetzen.

[MSfree]

Meine Frage zielte eher auf Unternehmensnetzwerke ab, da wäre eine Verschlüsselung wohl unumgänglich.

Jein,

In Unternehmen müssen ja immer mehr oder weniger große Gruppen miteinander am gleichen Thema arbeiten. Innerhalb der Gruppe kann es keine Geheinisse geben, die müssen sich ja austauschen können. Hier ist Verschlüsselung also nicht nötig. Das Subnetz einer Gruppe kann man auch ohne interne Verschlüsselung von Rest des Unternehmens trennen, Stichwort Firewall.

Erst, wenn Daten, wie es heutzutage so modern ist, in der "Cloud" gespeichert werden, kommt man um Verschlüsselung nicht herum.

Stretch stable erlaubt noch nicht die Nutzung von nfsv4.

Doch. Sogar mein älterer Jessieserver kann schon NFS4.

Eine weitere Frage die ich noch hätte : Kann man ACLs mit NFS bedenkenlos einsetzen?

Da bin ich ein wenig überfragt. ACL bedingt zunächst einmal ein Dateisystem auf dem Server, das ACL unterstützt. Ausserdem holt man sich mit ACL Probleme ins Haus, die man mit einfacherer Benutzer- und Gruppenverwaltung gar nicht erst hätte.

[Trollkirsche]

Meine Frage zielte eher auf Unternehmensnetzwerke ab, da wäre eine Verschlüsselung wohl unumgänglich.

Jein,

In Unternehmen müssen ja immer mehr oder weniger große Gruppen miteinander am gleichen Thema arbeiten. Innerhalb der Gruppe kann es keine Geheinisse geben, die müssen sich ja austauschen können. Hier ist Verschlüsselung also nicht nötig. Das Subnetz einer Gruppe kann man auch ohne interne Verschlüsselung von Rest des Unternehmens trennen, Stichwort Firewall.

Erst, wenn Daten, wie es heutzutage so modern ist, in der "Cloud" gespeichert werden, kommt man um Verschlüsselung nicht herum.

Stretch stable erlaubt noch nicht die Nutzung von nfsv4.

Doch. Sogar mein älterer Jessieserver kann schon NFS4.

Eine weitere Frage die ich noch hätte : Kann man ACLs mit NFS bedenkenlos einsetzen?

Da bin ich ein wenig überfragt. ACL bedingt zunächst einmal ein Dateisystem auf dem Server, das ACL unterstützt. Ausserdem holt man sich mit ACL Probleme ins Haus, die man mit einfacherer Benutzer- und Gruppenverwaltung gar nicht erst hätte.

Hmm dann muss ich das mit NFSv4 wohl nochmal testen.

Bezüglich ACL.. Der Server läuft unter Buster testing.

Die Idee der Nutzung hinter ACL ist die Steuerung über mehrere Gruppen. Welche Probleme im Bezug auf ACL meinst du konkret?

[Trollkirsche]

Irgendetwas klappt noch nicht.

Ich habe auf dem Server ein Pseudodateisystem erstellt und die exportfs Einträge dementsprechend angepasst.
Vorher jedoch noch den nfs Server gestoppt per systemctl und die Einträge in den Kernel neu eingelesen per exportfs -ra

Dann habe ich die Einträge der fstab im Client angepasst, wie unter dem Artikel hier beschrieben:
<nfs-server>:/ /mnt/nfsv4-test nfs nfsvers=4,rw 0 0

Das manuelle mounten hat funktioniert.

Wenn ich jedoch den PC neu starte, sehe ich in der GUI zwar die einträge für die shares, aber sie sind leer..

Weiss einer, was ich falsch gemacht habe?

edit : Das manuelle mounten zeigt mir ebenfalls nur leere Ordner auf dem Client an..

[Trollkirsche]

Zu meinem Post oben, ich hab die Lösung gefunden.

Bei nfsv4 muss per mount das lokale Share Verzeichnis mit dem Pseudofilesystem gebindet werden.
Das habe ich getan und nun funktioniert alles per nfsv4. Ich kann nun auf die Verzeichnisse per Client wieder zugreifen.

Bis dann!