[gelöst] Samba: User verstehen

Probleme mit Samba, NFS, FTP und Co.
Antworten
MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

[gelöst] Samba: User verstehen

Beitrag von MoonKid » 19.01.2017 23:43:21

Bin kurz davor einen eigenen Samba-Server aufzusetzen und lese dazu diverse Wikis/HowTos.

Was ich bisher fand, waren step-by-step-Anleitungen ohne Background-Infos. Daher verstehe ich das mit den Usern nicht.

Was ist ein Samba-User konkret?
Ist ein Samba-User auch ein Linux-User auf dem Server-Rechner?
Hatte aber auch gelesen, dass Samba Passwörter anders speichert, als Linux.
Muss ich einen Linux-User anlegen, um einen gleichlautenden Samba-User zu haben? Passwörter werden aber zwei angelegt?

Bin da etwas verwirrt.
Zuletzt geändert von MoonKid am 12.02.2017 11:28:47, insgesamt 1-mal geändert.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Samba: User verstehen

Beitrag von MSfree » 20.01.2017 08:18:49

MoonKid hat geschrieben:Ist ein Samba-User auch ein Linux-User auf dem Server-Rechner?
Ja, ein Linuxuser ist Voraussetzung für einen Sambauser.
Muss ich einen Linux-User anlegen, um einen gleichlautenden Samba-User zu haben?
Jein.
Man kann Samba so automatisieren, daß bei Anmeldung eines unbekannten Benutzers ein Linuxuser erstellt wird, mit dem dann ein Sambauser erzeugt wird.
Passwörter werden aber zwei angelegt?
Jein.
Auf das Linuxpaßwort kann man verzichten, wenn der User nur auf die Sambashares zugreifen können soll.

Benutzeravatar
Huck Fin
Beiträge: 1202
Registriert: 10.03.2008 17:10:30

Re: Samba: User verstehen

Beitrag von Huck Fin » 20.01.2017 09:16:09

Ich denke, der Linuxuser ist notwendig, da man ja Rechte (r-w-x) für User und Gruppen verwalten muss.

TomL

Re: Samba: User verstehen

Beitrag von TomL » 20.01.2017 11:28:44

MoonKid hat geschrieben:Bin kurz davor einen eigenen Samba-Server aufzusetzen und lese dazu diverse Wikis/HowTos.
Was ich bisher fand, waren step-by-step-Anleitungen ohne Background-Infos. Daher verstehe ich das mit den Usern nicht.
Ja, das ist einer der für mich am schwierigsten zu vermittelnden Punkte, wenn man das wie gewohnt mit Windows-Augen betrachtet. Unter einer Standard-Debian-Einrichtung zweier Maschinen, von denen der "Admin" einen als Server mit Samba nutzen möchte und den anderen als Arbeitsplatz-Enduser-PC, also als Client, braucht man quasi eine dreifache User-Einrichtung.

Anders als unter Windows werden unter Debian Benutzer-Berechtigungen nicht von ganz "oben" bis nach "unten" per default synchronisiert durchgereicht. Auch können Rechte auf Dateien nicht abschließend vom Client auf dem Server gesetzt werden. Das heisst, ich kann nicht so einfach ein Recht auf eine Datei setzen oder vergeben, welche auf dem Samba-Server gespeichert ist. Samba legt letztendlich die Datei auf dem Server an und setzt die Rechte dafür ..... innerhalb des vom Linux erlaubten Rahmens. Das bedeutet in der Folge, dass die Rechte, die ich von einer Samba-Datei auf dem Client angezeigt bekomme, nur Fake-Anzeigen sind, die überhaupt nicht mit den Rechten übereinstimmen müssen, die tatsächlich auf dem Server angelegt sind.

Ein Beispiel: Der Server-User "Fritz" hat die UID 1005, der Client-User "Otto" hat auf dem Client-PC auch die UID 1005. Nun würde der Client-User eine dem Server-User 1005 (also Fritz) gehörende Datei als dem Besitzer "Otto" gehörend angezeigt werden. Das ist natürlich Unsinn. Um dieses Dilemma zu lösen, kann man UID- und GID-Parameter beim Mounten setzen, die quasi in der Client-Anzeige einen Besitzaufkleber auf die wirklichen Rechten draufpappen.... also das ist wirklich nix anderes als ne Tapete, die die Wand verbirgt.... nur um eine Anzeige zu bereinigen. Ein technischen Effekt aufs Speichern hat es nicht. Aber das funktioniert trotzdem ausreichend gut.

Man kann Samba an folgende wesentliche Regeln festmachen:
1. Auf dem Client-PC muss ein User vorhanden sein

2. Auf dem Server muss ebenfalls ein User vorhanden sein. In unserer Vorstellung ist das der gleiche User wie auf dem Client, technisch betrachtet sind das aber 2 User

3. Auf dem Server verwaltet Samba ein eigenes Berechtigungssystem, welches sich aber nur innerhalb der von diesem Host vergebenen Linux-Rechte bewegen kann. Das heisst, samba kann auf diesem Host keine Linux-Mindestrechte unterschreiten und sich auch nicht über Linux-Maximalrechte hinwegsetzen.

4. Beim User dieser zwei Systeme kann es sich durchaus um die gleiche Person handeln, er kann aber trotzdem auf beiden Systemen einen unterschiedlichen Namen und Password haben. Eben deshalb, weil er sich sowieso auf jeder Maschine explizit identifizieren muss. Der Einfachheit halber verwendet man aber immer gleichen Anmeldenamen und gleiches Password. Schaut man jedoch auf die UID des Users beider Rechner, so kann man feststellen, dass die UIDs evtl. unterschiedlich sind.... eben deshalb, weils sie nicht per default synchronisiert werden.

5. Da Samba ein eigenes Berechtigungssystem berücksichtigt, muss ein vom Client-PC zugreifender User eben auf diesem Server auch als Samba-User eingerichtet werden. Aber es können nur Samba-User eingerichet werden, die gleichzeitig auch auf diesem Host reguläre Linux-User sind..

6. Theoretisch wäre es auch hier denkbar, dem Samba-User (zwar mit gleichem Namen, dennoch) ein vom Linux abweichendes Password zu vergeben. Aber auch das ist aus praktischer Sicht wenig sinnvoll.

7. Wenn ein Client-User sich mit einer Samba-Ressource verbinden möchte, so benötigt er zwei Anmeldungen: 1. die auf seinem Client-PC, 2. beim Verbinden zum Server den entsprechenden Samba-User und das Samba-PWD. Interessant ist, dass hierbei der Linux-User auf dem Server nicht verwendet wird - der ist nur dafür notwendig, damit man überhaupt den Samba-User auf dem Server anlegen kann.

Was kann ich nur mit diesen Anmeldedaten tun...?... als erstes natürlich die Grundfunktion: Anmelden als User auf dem Client und mit gleichem User-Namen + PWD die Samba-Freigaben vom Server verbinden. Aber richtig spannend wird es, wenn sich z.B. in einer Familie auf einem Client mehrere Personen zu unterschiedlichen Zeiten anmelden. Da wird es mit dem Mounten der Freigaben in der statischen fstab nämlich kompliziert, weil die fstab die Freigaben vor der Anmeldung mountet. Das heisst, man kann das an diesem Punkt gar nicht User-Anmeldungsbezogen handhaben.

Für dieses Problem gibt es verschiedene Ansätze. Einer davon wären die PAM-Mounts, die tatsächlich analog zu Windows userbezogen nach der Anmeldung stattfinden. Ich habe das ausführlich getestet und bin dann für unsere Anwendungen zu dem Schluss gekommen, dass traditonell über fstab bzw. mein Script "mountctl" und einer Unit "mountctl.service" für uns die bessere Variante ist.
Sowohl auf dem Server als auch auf allen Clients sind unsere User unter Linux und unter Samba eingerichtet. Ich -als admin- mounte auf allen Clients die 'öffentlichen' Freigaben unter meinen Server-Zugangsdaten, also die Freigaben, auf die alle zugreifen müssen und erlaube dann den anderen Familienmitgliedern den Zugriff auf 'meine' mounts . An dem Punkt könnte man anmerken "aber dann müssten doch die anderen Mitglieder gar nicht auf dem Server angemeldet sein". Ja, das ist richtig, aber neben den öffentlichen Mounts finden mit den persönlichen Anmeldedaten der anderen jeweils auch noch mounts in deren eigene lokale Client-Homedirs statt. Also z.B. deren auf dem Server gespeicherten Mail-Profile, oder eben deren eigene private auf dem Server gespeicherten Daten-Verzeichnisse, die auch ins lokale eigene Client-Home-Dir gemountet werden.

So.... als erster Rundumschlag wird das wohl reichen.... wenn noch was unklar ist, frag einfach noch mal....

Hth

Benutzeravatar
TRex
Moderator
Beiträge: 8038
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: Samba: User verstehen

Beitrag von TRex » 20.01.2017 13:14:11

TomL hat geschrieben:Ein Beispiel: Der Server-User "Fritz" hat die UID 1005, der Client-User "Otto" hat auf dem Client-PC auch die UID 1005. Nun würde der Client-User eine dem Server-User 1005 (also Fritz) gehörende Datei als dem Besitzer "Otto" gehörend angezeigt werden. Das ist natürlich Unsinn. Um dieses Dilemma zu lösen, kann man UID- und GID-Parameter beim Mounten setzen, die quasi in der Client-Anzeige einen Besitzaufkleber auf die wirklichen Rechten draufpappen.... also das ist wirklich nix anderes als ne Tapete, die die Wand verbirgt.... nur um eine Anzeige zu bereinigen. Ein technischen Effekt aufs Speichern hat es nicht. Aber das funktioniert trotzdem ausreichend gut.
Vorsicht TomL, nicht dass du das jetzt mit NFS verwechselt. Bei Samba meldest du dich mit einem Benutzernamen an, deine ID wird nicht übertragen.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!Wie man widerspricht

TomL

Re: Samba: User verstehen

Beitrag von TomL » 20.01.2017 13:38:21

TRex hat geschrieben: Bei Samba meldest du dich mit einem Benutzernamen an, deine ID wird nicht übertragen.
Ja, richtig, GENAU DAS sollte das Beispiel ja verdeutlichen. Man meldet sich zwar mit Namen an, aber diverse Client-Filemanager erzeugen möglicherweise ihre Anzeige über die Datei-Rechte-UID's der auf dem Server gespeicherten Dateien ... und das führt dann ggf. zu einer falschen Anzeige. Dieses Phänomen kann man einfach reproduzieren.Und genau diese fehlerhafte Anzeige beheben die UID- und GID-Parameter im Mountbefehl - die zwar keinen Einfluss auf die tatsächlichen Rechte haben, sondern nur auf die Anzeige, bzw. auf das, was der bekommt, der diese Rechte liest.

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 20.01.2017 19:43:35

Geiles Zeug! Das musst du unbedingt in einer FAQ, einem HowTo oder Blog-Post verewigen.

Zu den UID hab ich noch mal ne Nachfrage. In deinem Beispiel...

Sieht der admin auf derm Samba-Server:

Code: Alles auswählen

-rw-r--r--  1 Fritz Fritz      476 Nov 15  2015 myfile
Und der Benutzer Otto auf einem Client, sieht an der Stelle aber

Code: Alles auswählen

-rw-r--r--  1 Otto Otto      476 Nov 15  2015 myfile
Weil beide auf ihrem jeweils eigenen System die UID 1005 haben. Soweit richtig verstanden?

Wie und wo kommen hier die mount-Parameter ins Spiel? Was würden die an der Ansicht verändern?

Und kann man beim Anlegen eines Linux-Nutzers die UID eigentlich beeinflussen, um solche Dinge zu umgehen? z.B. könnte man ID-Räume (wie bei IPs) vergeben. Auf dem Server alle Nutzer 1*** und auf dem Client alle 2*** usw.

TomL

Re: Samba: User verstehen

Beitrag von TomL » 20.01.2017 20:25:52

MoonKid hat geschrieben:Weil beide auf ihrem jeweils eigenen System die UID 1005 haben. Soweit richtig verstanden?
Genau das ist so richtig. Und falls es auf dem Client zufällig keinen User gibt, der ebenfalls die UID 1005 hat, würde da einfach nur 1005 stehen.
MoonKid hat geschrieben:Wie und wo kommen hier die mount-Parameter ins Spiel? Was würden die an der Ansicht verändern?
Das wäre im Mount-Statement unterzubringen, hier als Beispiel etwa so:

Code: Alles auswählen

mount //10.10.1.2/PublicData /media/PublicData -t cifs  -o credentials=/home/thomas/.smbcredentials,uid=thomas,gid=sambauser,rw,nosuid,nodev,noexec,async
Das hat keinen Einfluss auf die tatsächlichen Rechte, wie sie vorliegen oder auf dem Server gesetzt werden, hier würde dann einfach bei Deinem ls-Befehl mein Name als User und die Group rauskommen.... die natürlich beide existieren. Und in der Gruppe Sambauser sind eben alle Familien-Mitglieder hinterlegt, die auf die Public-Dirs zugreifen dürfen. Also alle sehen hier das gleiche. Aber mal ehrlich, da hat noch nie einer drauf geachtet.... wenn die Daten zugänglich sind, sind alle zufrieden.... wem sie laut Linux gehören, interessiert hier keinen. *fg*
MoonKid hat geschrieben:Und kann man beim Anlegen eines Linux-Nutzers die UID eigentlich beeinflussen, um solche Dinge zu umgehen? z.B. könnte man ID-Räume
Ja, das geht alles. Den Ehrgeiz hatte ich zu Anfang auch.... ich wollte das wie unter Windows haben, alles schön synchron. Aber das ist eine solch sinnlose Arbeit, an der man bei jedem PC erneut anfängt, wenn man ihn neu aufsetzt. Sobald du nur irgendwie nicht die absolut gleiche Reihenfolge beim adduser bei der Einrichtung der User einhälst, knallt es... und dann fängt man an, systemweit die UIDs für alle Dateien zu kontrollieren und ggf von Hand zu korrigieren. Bis ich zu dem Schluss kam, dass ich einen an der Waffel hätte, wenn ich das weiter so mache *lacht* Vor allen Dingen braucht man das auch wirklich nicht. Auf dem Samba-Server werden bei mir generell alle Dateien auf öffentlichen Freigaben mit dem/der gleichen Standard User:Group gespeichert. Was die Clients nachher "oben" sehen, regelt das Mount-Statement. Die Dateien für die privaten Mounts werden allerdings mit dem/der usereigenen User:Group gespeichert. Soweit ich weiss, kann Debian auch die Synchronisation zwischen Client und Server, mit nem Domain-Controller oder wie auch immer... ich habe mich damit mangels Interesse nie befasst. Das was Debian und Samba onboard mitbringen, ist für mein lokales Netzwerk völlig ausreichend.... Fileserver (Private und Public-Daten), Printserver, VPN-Server, Medien-Server, Cloud-Server, Postfach-Server... das leistet alles mein kleiner Debian-Server.... und zwar völlig zufriedenstellend.

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 28.01.2017 22:53:28

TomL hat geschrieben:Das wäre im Mount-Statement unterzubringen, hier als Beispiel etwa so:

Code: Alles auswählen

mount //10.10.1.2/PublicData /media/PublicData -t cifs  -o credentials=/home/thomas/.smbcredentials,uid=thomas,gid=sambauser,rw,nosuid,nodev,noexec,async
Das hat keinen Einfluss auf die tatsächlichen Rechte, wie sie vorliegen oder auf dem Server gesetzt werden, hier würde dann einfach bei Deinem ls-Befehl mein Name als User und die Group rauskommen.... die natürlich beide existieren. Und in der Gruppe Sambauser sind eben alle Familien-Mitglieder hinterlegt, die auf die Public-Dirs zugreifen dürfen.
Danke für deine ausführliche Beschreibung. Es wird langsam klarer.
Aber wenn ich mich jetzt hinsetze und eine smb.conf anlege und die Ordner auf dem Server, wird mir doch wieder schwindlig. Mir is nicht so ganz klar, welche der Ordner welche Rechte/Owner haben sollten. Vielleicht denke ich auch zu kompliziert?

Kleine Nebeninfo: Meine bisherigen Samba-Erfahrungen basieren auf einem QNAP-NAS bei dem man auf einer Web-Oberfläche eingies (aber leider nicht alles) einstellen konnte.

Mal ein stark vereinfachtes Beispiel:
Auf dem Server sollen alle Samba-Shares unterhalb von /mnt/raid/ liegen. Das wären
  • /mnt/raid/Multimedia
  • /mnt/raid/Wichtig
Samba-User media darf nur lesend auf Multimedia und sonst nix zugreifen.
Samba-User admin soll so eine Art Samba-Root-User sein. Der darf nahezu überall lesen und schreiben. Er hat aber keine root-Rechte auf der Samba-Maschine, sondern fungiert nur im Kontext der Samba-Shares als "mächtigster" User.

Muss ich diese Shares überhaupt explizit mit mkdir anlegen? Oder reicht es, wenn ich Samba passend konfiguriere und der legt mir die Shares dann schon passend an, falls sie noch nicht vorhanden sind?

Würde es Sinn machen das so auf dem Server anzulegen?

Code: Alles auswählen

drwxrwxr-x 1 admin admin  4096 Jan 20 00:29 Multimedia
Hier fängt mein Problem schon an. Others können lesend darauf zugreifen. Es sollte aber nur der Eigentümer/Gruppe UND media darauf lesen können.
Also gefühlt würde ich grundsätzlich Others nie Rechte auf ein Samba-Share geben. Naja und in der Samba-Conf gibts ja auch nochmal "Rechte". :roll:

TomL

Re: Samba: User verstehen

Beitrag von TomL » 28.01.2017 23:53:28

Du solltest versuchen, es nicht so kompliziert wie möglich zu machen, sondern nur so kompliziert wie nötig. Und Du solltest nicht die Anwender so dermaßen kastrieren, dass sie das Netzwerk nachher nicht mehr nutzen und wieder lokal speichern. Ich setze stattdessen auf Transparenz, gute Unterweisung und Eigenverantwortung. Und dabei würde ich bei der Einrichtung des Netzes nach folgenden Kategorieren unterscheiden:

1. Admin-Shares - Bereiche und Verzeichnisse, die nur mir zugänglich sind.
Rechte: thomas:thomas
Install = rwx-rwx-...

Und die Platten an sich, deren Rechte aber (siehe unten) gesetzt sind, bezgl. meiner UID also unten mit höherer Priorität. Besondere Jobs wie z.B. Backups oder ich muss ein Profil reparieren ... das läuft dann halt unter "root"
HD_1
HD_2, usw..

2. Public-Shares - Bereiche und Verzeichnisse, die alle verwenden dürfen
Rechte: thomas:sambauser
Multimedia = rwx-rwx-...
DatenAlle = rwx-rwx-...
PublicMail = rwx-rwx-...

3. Private-Shares - Persönliche usereigene Bereiche
Rechte: username:thomas
Daten = rwx-rwx-...
Mail = rwx-rwx-...

Und darüber hinaus werden bei mir Netzlaufwerke generell nach der Prämisse geshared, dass vom Netzlaufwerk keine ausführbaren Programme möglich sind = nosuid,nodev,noexec

Für die smb.conf kann ich Dir auch einen Tip geben. Du solltest eine Default-Conf immer zu allererst einmal sichern, bevor Du etwas veränderst. Zum Beispiel hier mit dem Befehl:

Code: Alles auswählen

cp /etc/samba/smb.conf /etc/samba/smb.conf.original
Der bei mir als nächstes folgende Schritt ist dafür zu sorgen, die Conf auf ein übersichtliches Maß zu bringen, also alles unwirksame zu entfernen.... siehe unten. Und der dritte Schritt ist es dann, bevor ich das im System produktiv starte, mir die Bedeutung der wirksamen Parameter in der Conf klar zu machen. Und wenn es dazu Fragen gibt, dann würde ich mich an ein solches Forum wie hier wenden.... und zwar bevor ich das produktiv setze. Der m.E. falsche Weg ist es, wenn man auf die Frage "Warum druckt mein Drucker nicht?" erst mal gegenfragen muss "Bist Du sicher, dass du einen Drucker hast?" *lacht*
https://www.samba.org/samba/docs/man/ma ... onf.5.html

Code: Alles auswählen

[global]
   workgroup = WORKGROUP
   server role = standalone server
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   security = user
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = no
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = no
   map to guest = bad user
   usershare allow guests = yes
   invalid users = root
   
#======================= Share Definitions =======================

[homes]
   comment = Home Directories
   browseable = yes
   read only = no
   create mask = 0777
   directory mask = 0777
   force create mode = 660
   force directory mode = 770
   valid users = %S

[printers]
   comment = All Printers
   browseable = no
   path = /var/spool/samba
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700

[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no

[testshare]
  path=/media/testshare
  writeable = yes
  browseable = yes
  guest ok = no
  force create mode = 0777
  force directory mode = 0777
Die Public-Shares kriegen bei mir alle

Code: Alles auswählen

force user = thomas
force group = sambauser
create mask = 0660
directory mask = 0770
force create mode = 0660
force directory mode = 0770
Der (nur 1) Admin-Share

Code: Alles auswählen

force user = thomas
force group = thomas
create mask = 0660
directory mask = 0770
force create mode = 0660
force directory mode = 0770
Lediglich beim Anlegen der Mount-Points und der Binds auf dem Server muss man dann eben einmalig auch die Linux-Rechte passend setzen. Aber dran denken, je komplizierter Du das aufbaust, umso komplizierter ist es, wenn man bei einer neuen Platte alles reproduzieren muss. Einfache Strukturen, einfache Regeln - bei uns muss es nur wirksam für/gegen Laien und Familienmitglieder sein.

Letztendlich muss man bei solchen Sachen auch Backup-Strategien bedenken. Das heisst, das sollte nach Möglichkeit von allen Usern unbemerkt ablaufen und trotzdem sind alle Daten regelmäßig gesichert. Bei uns finden jeden Monat vom 1. bis 4. vier unterschiedliche Initial-Backups statt. Dann beginnend am 8., am 16. und am 24. jeweils über weitere 3 Tage weitere 3 inkrementelle Updates.... alles immer morgens um 5 Uhr. Das heisst, ich habe in einem rollierenden Verfahren immer 3 frühere Versionen. Darüber hinaus wandern von 3 USB-Platten so alle 4-8 Wochen rollierend eine ins Schließfach. Wenn da jetzt wirklich mal was passieren sollten, scherts mich echt nicht weiter. Aber solche Sachen solltest nur nicht so einfach in der Planung vergessen.
Zuletzt geändert von TomL am 03.02.2017 10:35:53, insgesamt 1-mal geändert.

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 31.01.2017 15:48:04

Danke für die tiefen Einblicke in deine Config. ;)

Mein Grundgedanke ist der, dass ich hier einen Windows-Rechner/User im Netzwerk habe. Das NAS nutze ich auch als Backup-Medium. Der Windows-Rechner darf auf keinen Fall lesend/schreibend (z.B. wg. Verschlüsselungs-Trojanern) auf diese Bereiche zugreifen können. Deswegen bekommt der eigentlich seine eigenen Shares. Aber die Medien-Ordner (Musik, Videos) sollte er lesen können (dafür gibt es den User media), jedoch nicht schreiben.

Ohne GUI (wie z.B. im QNAP OS) ist es schwieriger da gedanklich rein zu kommen.

Ich setz mich dran...

TomL

Re: Samba: User verstehen

Beitrag von TomL » 31.01.2017 19:15:58

Ist doch kein Problem, dann erstellst Du einfach 2 "binds" auf das MultiMedia-Verzeichnis. Das eine als reguläres mit normalen Rechten für normale Clients, und das zweite seitens Samba und Linux-Rechten mit Nur-Lesen-Rechten für die Windows-Clients. Und dann mountet der Windowsrechner eben den rechtelosen Share und fertig ist die Baustelle.

BTW:
Das ist nicht meine Config, sondern nur vereinfachtes Anschauungsmaterial .

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 31.01.2017 20:28:54

TomL hat geschrieben:Ist doch kein Problem, dann erstellst Du einfach 2 "binds" auf das MultiMedia-Verzeichnis. Das eine als reguläres mit normalen Rechten für normale Clients, und das zweite seitens Samba und Linux-Rechten mit Nur-Lesen-Rechten für die Windows-Clients. Und dann mountet der Windowsrechner eben den rechtelosen Share und fertig ist die Baustelle.
Ui! Das war jetzt zu schnell. :D "binds"? Ich rate ins Blaue: Kann man abhängig von der Client-IP unterschiedliche Rechte für das gleiche Share setzen?

TomL

Re: Samba: User verstehen

Beitrag von TomL » 31.01.2017 21:28:41

MoonKid hat geschrieben:Ich rate ins Blaue: Kann man abhängig von der Client-IP unterschiedliche Rechte für das gleiche Share setzen?
Nee, nicht unterschiedliche Rechte für den gleichen Share, sondern ZWEI Shares auf die gleiche Ressource mit unterschiedlichen Rechten. Schau Dir mal meinen Vorschlag für die Verzeichnisstruktur des Servers an:

Code: Alles auswählen

\
 +- bin
 +- boot
 +- dev
 +- home
    + goofy
      + daten                        Mountpoint für User-Daten
    + donald
      + daten                        dto.
    + lupo
      + daten                        dto.
 +- usr
 +- opt
 +- media                            Mountpoints des Servers + Sambashares
    + Install
    + DatenAlle
    + MultiMedia
    + MultiMediaRO                   Samba = Read Only
 +- usw.
   
 +- LanShares                        Tatsächliche (!) Datenverzeichnisse                  
    + Install                        Admin-Dateien wie Deb-Packs, Conf-BAKs, Settings, Dokus, etc. 
    + HomeDirs                       Persönliche 'private' User-Daten mit Zugriff nur für den User
      + goofy
        + daten
        + mail
      + donald
        + daten
        + mail
      + lupo
        + daten
        + mail
    + DatenAlle                      Gemeinsame "Arbeits"-Daten
      + Dirs nach Bedarf
    + MultiMedia                     
      + Filme
      + Buecher
      + Musik
Die Aufmerksamkeit gilt jetzt hier 3 wichtigen Verzeichnissen:
1. /home und die jeweiligen Userverzeichnisse,
die bei mir nicht die üblichen Shell-Unterverzeichnisse enthalten. Eigentlich sind es weitestgehend leere Verzeichnisse, weil die User sich ja hier nicht lokal anmelden, die aber den Mountpoint "daten" enthalten. Achtung, das ist NUR ein Mountpoint und KEIN Datenverzeichnis. Der Hintergrund ist, das Samba diesen Mountpoint auf dem Client passend zum User "bindet", das heisst, es sind keine userbezogenen Einstellungen notwendig, Samba regelt das perfekt über den Homedir-Share. Ich habe an dieser Stelle keine server-gespeicherten Profile eingerichtet, sondern habe tatsächlich nur Arbeits-Daten vorgesehen, also alles, was schwer reproduzierbar ist, oder nur mit sehr hohem Aufwand wiederherstellbar ist. Die normalen Home-Dir-Profile habe ich alle lokal gelassen, weil ich das Backup vom Server auf das wesentliche reduzieren will.

2. /LanShares,
welche die echten im Lan angebotenen Daten und Verzeichnisse an einer Stelle zentral speichern, auf die die User aber nicht direkt zugreifen können, sondern nur indirekt über die Mountpoints in /media. Das "alles zusammen gespeichert" ist später total praktisch, wenn man sich um die Datensicherung kümmert. Man muss nicht selektieren, sondern sichert einfach dieses Verzeichnis als Ganzes und kann sicher sein, nichts vergessen zu haben.

3. /media
enthält die Mountpoints, in welches die tatsächlichen Verzeichnisse ge'bind'et werden. Die Samba-Share-Einstellungen beziehen sich nicht auf die Original-Dirs in /LanShares, sondern auf diese Mountpoints in /media.

Und diese (hier manuellen) bind's stehen (iüS) in der fstab und werden automatisch beim Boot abgearbeitet. Ich habe die hier mal 'als manuell' eingefügt, um damit zu spielen und zu testen.

Code: Alles auswählen

mount --bind /LanShares/Install     /media/Install
mount --bind /LanShares/DatenAlle   /media/DatenAlle
mount --bind /LanShares/MultiMedia  /media/MultiMedia
mount --bind /LanShares/MultiMedia  /media/MultiMediaRO

mount --bind /LanShares/HomeDirs/goofy  /home/goofy/daten
mount --bind /LanShares/HomeDirs/donald /home/donald/daten
mount --bind /LanShares/HomeDirs/lupo   /home/lupo/daten
Ergänzender Hinweis:
- Beim MultiMediaRO-Share für den Windows-Client entweder "read only=yes" oder "writetable=no" in der smb.conf eintragen
- Beim Admin-Share "Install" würde ich "browsable=no" einstellen und die Rechte auf mich begrenzen, ebenfalls smb.conf.
- Wenn Du Dir einen "browsable=no"-Share direkt auf /LanShares einstellst, hast Du mit einem Griff Zugriff auf alles, Ausnahme=User-Dirs, dafür sind Root-Rechte notwendig, was m.E. aber auch unbedingt richtig ist.

Auf dem Client sieht dann der user-eigene Datenmount so aus, der von samba auf dem Server mit dem korrekten Homedir gemountet wird. Ich habe dazu jeweils usereigene "smbcredentials" verwendet. Natürlich muss dazu auf den Client-PC-User-Homedirs jeweils der MountPoint "SHome" bestehen, der Name kann aber auch beliebig anders sein. Ich mag nur gerne sprechende Namen.

Code: Alles auswählen

mount //10.10.1.2/homes/daten     /home/lupo/SHome        -t cifs  -o username=lupo,defaults
mount //10.10.1.2/homes/daten     /home/goofy/SHome       -t cifs  -o username=goofy,defaults
Probiers mal und guck, was geht oder nicht, oder denk drüber nach..... und frag, wenn was unklar ist....

Hth

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 03.02.2017 00:00:53

(gelöst)
Hab jetzt ein bisschen rumgebastelt, aber kann mich nicht an meinen eigenen Shares anmelden.

Der User media ist in /etc/passwd vorhanden, er hat ein Home-Verzeichnis und ich kann mich auch lokal und sogar per SSH an der Maschine mit ihm anmelden.

Das relevante Share sieht so aus

Code: Alles auswählen

[Media]
path=/media/MediaRO
writeable = no
browsable = yes
guest ok = no
valid users = media ayako
write list = admin
Der relevante Abschnitt im log-file für den betreffenden Client sieht so aus

Code: Alles auswählen

[2017/02/02 23:42:36.330568,  2] ../source3/auth/auth.c:315(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [media] -> [media] FAILED with error NT_STATUS_NO_SUCH_USER
Ich bin in meinem Dateimanger (Thunar) über Windows-Netzwerk bis zum relevanten Verzeichnis durchgeklickt. Beim Anmeldedialog die passenden Daten (mehrmals!) eingegeben. Kein Erfolg. Keine Fehlermeldung. Auch smbclient gibt keine Fehler beim Verbindungsversuch aus. Er fragt das Passwort ab und zeigt mir dann alle Shares (so wie bei Option -L) und landet dann wieder auf der Bash.

Lösung: Ach natürlich muss man den User auch noch zum Samba-User machen. :facepalm: sudo smbpasswd -a <username>.

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 03.02.2017 10:31:52

TomL hat geschrieben:

Code: Alles auswählen

[homes]
   read only = yes
Gibt es einen Grund warum die Home-Dirs bei dir auf read only bei gesetzt werden? Dann können die User ja gar nicht in ihre eigenen Home-Verzeichnisse schreiben.

TomL

Re: Samba: User verstehen

Beitrag von TomL » 03.02.2017 10:45:29

Selbstverständlich haben die Anwender in meiner Konfiguration auch ein Schreib-Recht auf die an dieser Stelle gespeicherten Daten. Wie ich schon sagte, das ist nicht 'meine' smb.conf, sondern nur ein Anschauungsobjekt, worauf ich hin- und wieder zurückgreife.... so, wie jetzt hier im Thread eben auch. Aber Du hast natürlich Recht, im Kontext dieses Threads passt das überhaupt nicht zusammen. Deswegen habe ich das jetzt gerade oben korrigiert, so das nun alles zusammen ein stimmiges Bild ergibt.

Haben Dir meine Ausführungen bei Deiner Lösung ein wenig geholfen...?... das würde mich freuen......! Dabei gings mir mehr um das Verstehen der Zusammenhänge, und weniger um stupides Abarbeiten von Befehlsreihenfolgen. Wenn ja, ist das hier vielleicht noch mal verwendbar, denn diese Fragen kommen immer wieder neu.

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 03.02.2017 11:06:01

TomL hat geschrieben:Haben Dir meine Ausführungen bei Deiner Lösung ein wenig geholfen...?... das würde mich freuen......! Dabei gings mir mehr um das Verstehen der Zusammenhänge, und weniger um stupides Abarbeiten von Befehlsreihenfolgen. Wenn ja, ist das hier vielleicht noch mal verwendbar, denn diese Fragen kommen immer wieder neu.
Das hat absolut geholfen! Bin noch am Austesten. Wie gesagt, sollte man diesen Thread auf jeden Fall in einem Wiki/Blog verarbeiten. Besonders die Erklärung des Zusammenhangs von Linux- und Samba-Usern und der Ansatz mit dem "binds", war mir so bisher nicht untergekommen. Noch n kleiner Lesetip zum Thema User-Rechte in Samba: Endlich verstehen: Samba-Rechtevergabe.

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 03.02.2017 12:01:01

Diesmal kein Problem, sondern einen alternativen Lösungsvorschlag für mein bereits genanntes Szenario. Hier zur Dokumentation für andere, oder zum Zerreisen durch erfahrene Samba-Admins. :D

Szenario: In meinem Netz gibt es einen Windows-User (ayako). Das erachte ich grundsätzlich als risikoträchtig wegen Verschlüsselungstrojanern und anderer Schadsoftware, welche die Daten (u.a. auch Backups) gefärden würden. Es gibt ein Media-Verzeichnis in dem Videos, Musik usw für das gesamte lokale Netzwerk liegen. Der Linux/Samba-User media darf lesend darauf zugreifen. Alle Media-Player hier zu Hause (z.B. suspekte propritäre Geräte, Kodi, usw) nutzen diesen User, um Medieninhalte abzuspielen. Wenn ich was neues hinzufüge oder umschiebe, tue ich das als admin. Mein Windows-User möchte aber auch eigene Sachen da reinmachen können. Also bekommt er von mir Schreibrechte auf ein Unterverzeichnis in Media.

So!

Auf dem Server ist dieses reale Verzeichnis und das dazugehörige Unterverzeichnis für den Windows-User (auf einem RAID-Verbund).

Code: Alles auswählen

drwxr-xr-x 3 root root 4096 Feb  2 22:58 /mnt/raid/Media
drwxr-xr-x 5 ayako ayako 4096 Feb  3 10:58 /mnt/raid/Media/Ayako
Das erste "bind"e ich auf einen Share-Pfad.

Code: Alles auswählen

/mnt/raid/Media /media/Media none defaults,bind 0 0
Dazu der Abschnitt aus der smb.conf.

Code: Alles auswählen

[Media]
path=/media/Media
browsable = yes
guest ok = no
# keine Schreibrechte = nur Lesen
writeable = no
# zugelassene Benutzer (nur Lesen)
valid users = media ayako
# Ausnahme-User, der auch Schreiben darf (unabhängig von Option writeable)
write list = admin
Man sieht schon: media und auch der Windows-User ayako dürfen hier lesend zugreifen. Und admin darf als Ausnahme auch schreiben.

Nun das zweite "bind" für den Windows-User. Hier wird das Media-Unterverzeichnis einfach in den Home-Ordner des Windows-Users ge"bind"et.

Code: Alles auswählen

/mnt/raid/Media/Ayako /home/ayako/Media none defaults,bind 0 0
Der relevante Abschnitt dazu aus der smb.conf.

Code: Alles auswählen

[homes]
browsable = no
writeable = yes
create mask = 0700
directory mask = 0700
valid users = %S
Also in meiner Test-Umgebung (mit VirtualBox) scheint es zu funktionieren. Übrigens hab ich die unix-extensions aktiviert (falls das relevant sein sollte?).

Ich würde das "nested shares" oder "verschachtelte Shares" oder "Sub-Shares" nennen. Zu diesen Begriffen hatte ich einiges im Netz gefunden, aber mit ziemlich exotischen hinte-durchs-Auge-Lösungen. Meine Lösung erscheint mir fast zu einfach! Hab ich was übersehen? Ich brauche ja nicht mal einen MediaRO, wie Eingangs vorgeschlagen wurde. Was meint ihr?

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 08.02.2017 20:40:46

TomL hat geschrieben: Die Public-Shares kriegen bei mir alle

Code: Alles auswählen

force user = thomas
force group = sambauser
create mask = 0660
directory mask = 0770
force create mode = 0660
force directory mode = 0770
Woher kommt sambauser. Diese Gruppe existiert bei mir nicht.

Welche Linux-Dateirechte Owner und Gruppe hat das Public share. Alle müssen darauf lesen und schreiben können.

Nach meiner bisherigen Konfiguration, kann sich der Client zwar beim Public-Share einhängen, aber nix damit anstellen, weil er nicht die passenden Rechte hat.

TomL

Re: Samba: User verstehen

Beitrag von TomL » 08.02.2017 21:21:02

MoonKid hat geschrieben:Woher kommt sambauser. Diese Gruppe existiert bei mir nicht.
Das hatte ich hier erwähnt.
MoonKid hat geschrieben:Welche Linux-Dateirechte Owner und Gruppe hat das Public share. Alle müssen darauf lesen und schreiben können.
Bei mir haben der Admin-Share, Private-Shares und die Public-Shares alle die gleichen Linuxrechte, und zwar 770. Das sind aber nur die "Haupt"-Verzeichnisse, deswegen das X-Flag, den dort angelegten Files ist nur 660 erlaubt, also rw- rw- ---, siehe hier das Beispiel force create mode = 0660 und force directory mode = 0770. Das sieht für die Linux-Verzeichnisse i.ü.S. so aus:;

Code: Alles auswählen

     U   G   O
770  rwx rwx ---   Admin-Shares                         thomas:thomas
770  rwx rwx ---   Public-Shares                        thomas:sambauser
770  rwx rwx ---   Private-Shares in Server-Homedirs    {UserName}:{UserName}
Die "Ressource" hat also immer Schreib/Lese-Rechte (chmod) für 'User + Group', 'Other' hat keine Rechte. Aber ob der Zugriff dem Client-User erlaubt ist, erfolgt über die Linuxzuweisung von lokaler UID und GID zu diese Ressource (chown)

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 11.02.2017 13:53:38

Danke nochmal für die ausführliche Darstellung. Ah, (ich glaube) ich verstehe. Du hast die Gruppe sambauser selbst angelegt? Jeder deiner User ist dort Mitglied und hat daher die Gruppenrechte des Public-Verzeichnisses. Korrekt verstanden? Wenn ich das so sehe, erscheint es mir wieder so einfach. :D

TomL

Re: Samba: User verstehen

Beitrag von TomL » 11.02.2017 14:32:28

MoonKid hat geschrieben:Korrekt verstanden?
Yep!
MoonKid hat geschrieben:Wenn ich das so sehe, erscheint es mir wieder so einfach.
8)

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: Samba: User verstehen

Beitrag von MoonKid » 11.02.2017 20:16:20

Zu der Verwendung von mount --bind würde mich nochmal genau interessieren, warum du das machst. Du könntest ja auch symlinks verwenden, oder?

Gibt es technische Gründe, oder ist es mehr eine Geschmackssache?

Bisher hatte ich nur verstanden, dass Backups dadurch für dich einfacher sind, weil du nur ein großes Verzeichnis anfassen musst.

TomL

Re: Samba: User verstehen

Beitrag von TomL » 11.02.2017 23:12:57

Die Frage 'Symlink' oder 'Mount --bind' hat imho keinen Einfluss auf die Frage "Alle Share-Dirs in einzentrales Sub-Dir" oder "Mit beliebigen Share-Dirs das root-Dir / zerfleddern". Und nicht nur die Backups sind hier ein relevanter Faktor. Ich fühle mich besser dabei, wenn ich die primär-wichtigen Dirs (Sicherheit) des OS von den sekundär-wichtigen Dirs (nur Daten) der Shares konsequent trenne. Das wird umso plausibler, wenn ich sogar noch einen Schritt weiter gehe und auf das Root-Dir des Servers aus Sicherheitsgründen überhaupt keine Zugriff zulasse, sondern die Shares vollständig auf eine externe Platte oder ggf. auch auf eine eigene Partition ausgelagert habe. Die externe Platte (bzw. Partition) wird einmalig nach /media gemountet und die relevanten Shares dieser Platte werden dann via "binds" ebenfalls nach /media repliziert. Aber wie gesagt, das ist halt subjektiv eingeschätzt und insofern nur ein Teil meiner Vorstellung von "Server-Hygiene".
MoonKid hat geschrieben:Gibt es technische Gründe, oder ist es mehr eine Geschmackssache?
Ja, hier gibt es technische Gründe. Ein symlink ist nur eine Datei, die auf ein Verzeichnis oder Datei absolut oder relativ verzeigert ist. Ein Mount hingegen ist ein Kernelobjekt, also ein Objekt auf deutlich "tieferer Systemebene". Bei einem Chroot z.B. ist der symlink einer Ressource nach 'außen' tot, der Mount nicht. Dann gibts halt Anwendungen, die Symlinks erkennen und besonders darauf reagieren. So fragt z.B. DoubleCommander beim Kopieren "Symlink folgen?". Sagt man "nein", kopiert er nur die Symlink-Datei, anstatt des Inhalts im Original. Ein Symlink ist also nur eine Datei... eine, die gelöscht, umbenannt, gemove'd werden kann. Mir wäre bei Symlinks das latent vorhandene Risiko zu gross, durch eine Unachtsamkeit bei Wartungsarbeiten meine Daten zu zerschießen.

Möglicherweise gibts noch andere Gründe.... dafür oder dagegen.... aber so fit bin ich auch nicht in dieser Materie.

Antworten