SMB vs NFS4 und Nutzerrechte

Probleme mit Samba, NFS, FTP und Co.
TomL

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von TomL » 31.01.2020 12:00:32

Simaryp hat geschrieben: ↑ zum Beitrag ↑
30.01.2020 23:56:19
Brauche ich diese ganzen Sachen, die ich zu Printern angegben habe oder reicht es, einfach keinen Abschnitt zu Printern zu haben?
Ich nutzte samba nicht für den Netzwerk- Drucker, sondern Cups... was seit Jessie geradezu perfekt funktioniert.
Simaryp hat geschrieben: ↑ zum Beitrag ↑
30.01.2020 23:56:19
Was bringt mir das deaktivieren von netbios? Beziehungsweise wofür ist es gut. In den man pages steht, dass das für Win 2000 zB ok wäre, bei anderen Betriebssystemen (Windows?), aber Probleme macht.
Netbios (Port 139) ist an sich ein kritisches Protokoll... und nur Windows-Versionen bis Win2000 erfordern das zwingend. Microsoft hat das Protokoll wegen der Mängel auf ein TPC/IP-Basiertes (Port 445) geändert, welches alle späteren Windowsersionen natürlich auch unterstützen. Der Vorteil ist, eine potentielle Gefahrenstelle zu eliminieren. Port 139 ist nicht notwendig, bei mir gibts kein so altes Gerät oder Betriebssystem, welches das noch erfordern würde.

Das Problem der Berechtigungen ist, dass man Dir eigentlich nicht wirklich raten kann, was richtig ist.... weil man nicht so recht Deine Anforderungen oder Deine Vorstellungen zum Server kennt. Ich kann nur grob umreissen, wie ich das hier gelöst habe und warum das so ist.... ob das für Dich geeignet ist, habe ich keine Ahnung.
  1. Prämisse: Es gibt userbezogene, rein private Verzeichnisse auf dem Server, mit exklusiven Rechten nur für den User
  2. Prämisse: Es gibt allgemeine Verzeichnisse, auf die alle User zugreifen dürfen, Multimedia, Dateien von gemeinsamen Interesse
  3. Prämisse: Es gibt geschützte Verzeichnisse, die nur für den Admin (für mich) relevant sind
  4. Prämisse: Keine Server-Platte kann von den Clients als "himself" gemountet werden
  5. Prämisse: Auf den Serverplatten können durch die Clients keine Devices oder ausführbare Programme betrieben werden
  6. Prämisse: Das Handling muss einfach sein, der Aufwand auf den Clients minimiert gering, möglichst zentral, am Server via Samba... auf den Clients nur ein paar Dateien kopieren und ggf. die Gruppe 'sambauser' mit den berechtigten Usern anlegen.
  7. Prämisse: Die Datenstrukturen müssen Backups perfekt unterstützen
Zu 1.
Auf der Server-Platte (bei mir SSD) gibts ein Verzeichnis /media/Home, welches weiter jeweils unter dem Namen der Linux-User für jeden User ein eigenes Verzeichnis hat, was auch seitens der Rechte diesem Linux-User gehört. Die User selber haben keinen Zugang zu /media/Home, das ist kein Samba-Share! Über die Home-Section in der smb.conf können die User aber auf ihr Server-/home Zugreifen. Für jeden User findet nun einfach ein bind in der server->fstab statt, wo z.B. das User-Verzeichnis SSD->/media/Home/thomas lokal auf dem Server nach SSD->/home/thomas/SHome gebinded wird. Der User selber kann dann an seinem Client-PC mit einem Mount "/bin/mount //server/homes/SHome /home/%I/SHome" sein persönliches Server-Daten-Verzeichnis in sein lokales Homedire mounten. Samba unterstützt das wirklich perfekt. Der Vorteil ist, die Shares laufen immer genau unter dem User, der den Share mountet und bekommt auch die Rechte des Users. Zugriffe durch andere User im LAN ist gar nicht möglich... ebensowenig unerlaubte Übergriffe durch laufende Programme auf anderen Systemen... nur dieser User mit seinen Rechten hat Zugriff.
Die SSD ist ausschließlich gedacht für die sehr dynamischen Bewegungsdaten, Office-Dokumente, Mail-Systeme, Cal/Card-Dav, etc... also die typischen Daten aus dem Userspace mit hohem Änderungsaufkommen. Das Backup-Volumen soll idealerweise < 5GB bleiben, damit es noch via FTP auf den Web-Space (natürlich verschlüsselt) gesichert werden kann. Hier handelt es sich ja ausschließlich um durch oder von den Users selber laufend generierten Daten.... mit dem Attribut, dass diese Daten ohne aktuelles Backup nicht oder nur mit unverhältnismäßigen Aufwand wiederhergestellt werden können.

Zu 2.
Hier ists einfach... keine individuellen Rechte, die Gruppe wird generell mir RW auf die ID "sambausers" gesetzt. Auch das macht samba klasse. Hier ists ein Datengrab für statische Daten, typisch Multimedia, alles was groß ist, viel Speicherbedarf erfordert, sich nie oder kaum verändert (z.B. Foto-Archive), alles, was nur Kategorie 2 bei den Backups ist... ist ja bei Verlust alles mehr oder weniger leicht wieder beschaffbar. Das ist also eine klassiche HD mit mehreren TB.

Zu 3.
Ist ebenfalls einfach ...der Umstand, dass der Share nur mich als User zulässt, verhindert den Zugriff anderer. Auch das ist erfolgreich mit Samba gelöst. Meistens Install-Pakete, oder Source-Codes aus Project-Web-Sites. Wegen des teilweise hohen Speicherbedarfs und der wirklich leichten Wiederbeschaffbarkeit alles nur Kategorie 3 bezogen auf die Backups. Liegt alles in einem eigenen Verzeichnis auf der HD.

Zu 4.
Es sind in der smb.conf zwar Shares für die Platten/SSDs eingerichtet, aber die können nur im Terminal mit root-Rechten und nur von mir gemountet werden. Zu Wartungszwecken braucht man das natürlich. Ebenfalls erfolgreich mit Samba gelöst.

Zu 5.
Ist in den Mounts (noexec, nodev) auf dem Client geregelt, die durchgeführt werden, wenn sich ein User anmeldet. Das kann man umgehen, aber nur wenn man weiss wie... für normale User quasi unlösbar.

Zu 6.
Ist bei mir mit einem eigenen tool realisiert....

Zu 7.
Also... für mich war das mit einer der wichtigste Überlegungen überhaupt, die Datenstruktur an der Notwendigkeit der Backups auszurichten... denn gerade dafür will ich Erfolgsgarantien bezogen auf die Wiederherstellbarkeit wichtiger Daten. Aber ich will keinen individuellen Aufwand dafür... das soll mannlos laufen. Also die Backups waren echt eine Basis aller Überlegungen... auch das habe ich mit einem eigenen tool gelöst. Bei mir sinds mittlerweile nur keine 3 dedizierten Raspi's mehr, sondern ein Intel NUC mit 3 VMs... aber prinzipiell wurde die Logik 1:1 beibehalten.

Aber wie gesagt... das alles kann jetzt hier nicht mehr als nur eine Anregung sein... ein paar Ideen... was davon brauchbar ist, entscheiden Deine Anforderungen.

Simaryp
Beiträge: 108
Registriert: 29.11.2019 14:09:49

Re: SMB vs NFS4 und Nutzerrechte

Beitrag von Simaryp » 31.01.2020 13:25:25

Vielen Dank für deine ausführlichen Erklärungen. Ich glaube, dass geht schon über meinen Usecase weit hinaus.
Basierend auf unserer Diskussion hier, habe ich folgenden Plan für Nutzer und Gruppen erstellt:

Code: Alles auswählen

##Users and Groups
A lot of groups and users is needed to get a KISS like right management for stored data. The idea is to create one group for each dataset and add all the users to it that should have access to the folder. For not too complicated use cases the access can be controlled with the posix rules and no ACLs are needed. In principle some users don't need a home on the server for current needs but since there is no harm and maybe usefull if needs change, they are created anyway.

###Creation of users
The following users need to be created:
* tick
* trick
* track
* htpc (for access with HTPC)
* docker (for running docker containers)

For each do the following:
adduser <username> --gecos ""
and follow the instructions.

###Creation of groups
For each dataset we need an extra group. Groups can be added with the groupadd command, gid can be specified with the -g <number> option. Since a group for each user is added automatically, the folders with usernames are created already.
Check first if GIDs are available and copy the following to console:
groupadd -g 1003 media
groupadd -g 1004 fotos
groupadd -g 1005 tmp

###Setting rights for files
The idea is that all datasets and the recursive files and folders belong to the group with the dataset name. The owner of the files is set initially to one user that has to be member of that group. By setting the rights to ether 770 or 740 one can define if the other group members can only read or in addition write to the files and folders.

####Adding users to groups
usermod -aG track media fotos tmp tick
usermod -aG track media fotos tmp trick
usermod -aG media htpc
usermod -aG media docker

####Setting owner and file mode
chown -R tick:tick /pool/tick
chown -R trick:trick /pool/trick
chown -R tick:track /pool/track
chown -R tick:media /pool/media
chown -R tick:fotos /pool/fotos
chown -R tick:tmp /pool/tmp

find /pool/tick/ -type d -exec chmod 770 {} +
find /pool/tick/ -type f -exec chmod 660 {} +
find /pool/trick/ -type d -exec chmod 770 {} +
find /pool/trick/ -type f -exec chmod 660 {} +
find /pool/track/ -type d -exec chmod 770 {} +
find /pool/track/ -type f -exec chmod 660 {} +
find /pool/media/ -type d -exec chmod 750 {} +
find /pool/media/ -type f -exec chmod 640 {} +
find /pool/fotos/ -type d -exec chmod 770 {} +
find /pool/fotos/ -type f -exec chmod 660 {} +
find /pool/tmp/ -type d -exec chmod 770 {} +
find /pool/tmp/ -type f -exec chmod 660 {} +
Sambanutzer sind im Prinzip nur tick, trick, track und HTPC. Alles auf Linux-Rechnern. Die Benutzerverzeichnisse sind im Prinzip sowas wie ein /home Archiv. Da kommen halt alle Daten rein. Die eigentlichen /home Verzeichnisse auf den Rechnern sind nur noch sowas wie ein /tmp, um halt Dateien zu erstellen und bearbeiten und alles was dann fertig ist, kommt rüber in die Verzeichnisse mit dem Namen. Daneben gibt es noch Verzeichnisse, in denen Tick und Trick gemeinsam arbeiten und erstellen dürfen. HTPC soll halt nur in dem Mediaverzeichnis lesen dürfen, aber auf keinen Fall irgendwas ändern. Ich sehe gerade noch, dass noch ein /recordings Verzeichnis fehlt, welches ich auf der ssd und nicht im ZFS-Pool anlegen will, aber das ändert glaube ich für die grundlegende smb.conf erst mal nichts.

Ich will eigentlich nur, dass die Rechte und der Besitz so fortgeführt wird, wie vorgegeben, also dass die Gruppe immer die Gruppe des Verzeichnisses ist und jeder nur das darf, was auf dem Server eingestellt wurde. Ich will also keine extra Samba-Rechte, sondern es soll alles so laufen, als wären die Nutzer lokal am Werk.

Antworten