Grundsatzfragen zu Samba 4

[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!