ubuntuusers.de

Ich nutze Samba Version 4.15.13-Ubuntu (auf Ubuntu 22.04 LTS) und habe hier einige WindowsXP-, Windows10- und Ubuntu-Clients. Folgende Einstellung in /etc/samba/smb.conf ermöglicht die Nutzung als PDC für die WindowsXP-Clients und der zeitgleiche Zugriff auf die Freigabe via Windows10 und Ubuntu. Bitte nicht fragen, warum WindowsXP. Ist virtualisiert und wird für die Nutzung spezifischer Software durch nicht privilegierte Benutzer benötigt.

   server role = classic primary domain controller
   server min protocol = NT1
   lanman auth = yes
   ntlm auth = yes

Grundsätzlich funktioniert alles. Das ist schon mal gut. Ich habe mich aber dann nochmals mit den Rechten beschäftigt. Und ich habe keine ACLS oder dergleichen aktiv. Das ist aber dennoch ziemlich umfangreich, weil hier auch AND und OR Verknüpfungen erfolgen.

Da ist einmal diese Einstellung in /etc/samba/smb.conf hier, die verhindern soll, dass die UNIX-Rechte des jeweiligen Benutzers berücksichtigt werden.

obey pam restrictions = no

Ich habe dann die Freigabe "fest" auf die Benutzer und Gruppe verdrahtet. Die Benutzer sind alle Mitglieder der Gruppe mydms und haben vollen Zugriff.

   read only = No
   guest ok = No
   browseable = yes
   force group = mydms
   force user = mydms
   create mask = 0775
   directory mask = 0775

Ich möchte die force user rausnehmen, um über Gruppenmitgliedschaften für bestimmte Verzeichnisse den Zugriff einzuschränken. Auch das läuft und ich benötige keine ACLS und kein ActiveDirectory.

Aber beim Testen bin ich über folgendes gestoßen, dass irgendwie auch nicht gegoogelt bekomme.

Ein dir -al zeigt bei Word-Dateien die neu erstellt werden folgendes an:

-rwxrwxr--  1 dms dms   19456 Sep  3 12:45 Word6.doc

Wird die Datei bearbeitet und gespeichert sieht man folgendes

-rwxrwxr--+  1 dms dms   19456 Sep  3 12:45 Word6.doc

Da ist dann ein + bei den Rechten dran. Eventuell was ganz simples, aber ich verstehe es nicht und ich finde keine Erklärung via google. Auch ein nachträgliches chmod ändert da auch nichts dran. Alles vorgenannte sind nur Hintergrundinfos und haben hiermit evt. nicht wirklich etwas zu tun. Aber meine Frage ist, was bedeutet dieses + und welche Konsequenzen hat dies?

Hallo!

yauu: Aber meine Frage ist, was bedeutet dieses + und welche Konsequenzen hat dies?

Das + zeigt an, daß es ACLs gibt. Mit

getfacl Word6.doc

würdest du das sehen.

Hallo, danke für den prompten Hinweis.

Ich bin mir eigentlich ziemlich sicher, dass ich keine ACLs nutze.

Der Befehl getfacl geht bei mir nicht, weil

Command 'getfacl' not found, but can be installed with:
sudo apt install acl

Wie ohne installiertes Paket, ACLs unerwünscht zum Einsatz kommen sollen, wüsste ich jetzt nicht.

Die Besonderheit ist, dass sofern die Datei (über den Client) neu erstellt wird, zunächst einmal kein + angehängt wird. Erst nach einer Änderung geschieht dies.

Ich habe zudem wieder

obey pam restrictions = yes

[dms]
   comment = DMS
   path = /srv/dms
   read only = No
   guest ok = No
   browseable = yes
   force group = dms
   force user = dms
   create mask = 0775
   directory mask = 0775

gesetzt, jedoch ändert dies nichts an der Situation.

Wenn ich mit sudo ls -alh und stat arbeite, erhalte ich folgende Ausgaben für eine neu erstellte und geänderte Datei:

Neu erstellt:

-rwxrw-r--   1 dms dms    11K Sep  4 06:16  Word10.doc

und

  File: /srv/dms/Test/Word10.doc
  Size: 10752     	Blocks: 24         IO Block: 4096   regular file
Device: 802h/2050d	Inode: 109838781   Links: 1
Access: (0764/-rwxrw-r--)  Uid: ( 1001/     dms)   Gid: ( 1001/     dms)
Access: 2023-09-04 06:16:40.383553847 +0000
Modify: 2023-09-04 06:16:40.273739600 +0000
Change: 2023-09-04 06:16:43.531581404 +0000
 Birth: 2023-09-04 06:16:40.259552761 +0000

Geändert:

-rwxrwxr--+  1 dms dms    19K Sep  4 06:18  Word10.doc

und

  File: /srv/dms/Test/Word10.doc
  Size: 19456     	Blocks: 48         IO Block: 4096   regular file
Device: 802h/2050d	Inode: 109838789   Links: 1
Access: (0774/-rwxrwxr--)  Uid: ( 1001/     dms)   Gid: ( 1001/     dms)
Access: 2023-09-04 06:18:22.552452212 +0000
Modify: 2023-09-04 06:18:22.247000000 +0000
Change: 2023-09-04 06:18:22.540452106 +0000
 Birth: 2023-09-04 06:18:22.384450728 +0000

Was hier auffällt, ist das Ändern der Rechte beim Ändern der Datei. Die smb.conf gibt diesbezüglich nichts her. Ich habe noch einen ähnlichen Server, gleiche Samba-Version und ähnliche smb.conf aber Ubuntu 20.04. Da ändert sich nie etwas an den Rechten der Datei, wenn die einmal erstellt worden sind.

Gibt das einen Aufschluss, woher dieses + kommt? Aber mit einem obey pam restrictions = no bleibt es ja auch bei dem +

yauu schrieb:

Ich bin mir eigentlich ziemlich sicher, dass ich keine ACLs nutze.

Damit bist Du aber mit Sicherheit im Irrtum. das Zeichen + in der Ausgabe von ls ist nun einmal ein untrügliches Zeichen, dass ACL benutzt werden.

Ok, ich habe nun mit Blick auf die Samba-Dokumentation zur Einrichtung von ACLs und dem Befehl

sudo testparm -v

die aktive Samba-Konfiguration hinsichtlich einer möglichen irgendwie unbewussten Konfiguration einer Nutzung von ACLs abgeglichen. Gemäß der Dokumentation müssten folgende Parameter in der smb.conf gesetzt sein:

vfs objects = acl_xattr
map acl inherit = yes

Aber in meiner(!) sind diese Werte wie folgt belegt:

vfs objects = 
map acl inherit = No

Also sind eigentlich keine ACLs aktiv. Aber jetzt kommt das Besondere, es betrifft nur MS Office Dokumente und nur dann wenn diese zumindest einmal gespeichert werden.

Und testparm gibt als Standard in Sachen ACLs folgende Parameter aus:

acl allow execute always = No
acl check permissions = Yes
acl flag inherited canonicalization = Yes
acl group control = No
acl map full control = Yes

Aber ich verstehe diese nicht als ACL ein oder aus, sondern als weitergehende Konfiguration, wenn ACL zum Einsatz kommt.

Obwohl es keine Probleme bei der Nutzung zu geben scheint, ist das unbefriedigend und ich muss ab irgendeinem (Zeit-)Punkt mit einem (unerwarteten) Problem rechnen.

Hallo!

Spricht was dagegen, wenn du das Paket acl installierst und dann schaust, welche Berechtigungen per acl gesetzt wurden? Vielleicht bringt das einen Hinweis auf die Lösung.

Das Word acl setzt, scheint öfter vor zukommen (Link). Demnach könnte die Lösung beim Setzen der Rechte liegen. Um unabhängig von den bereits vorhandenen Rechte zu werden, wäre meine Empfehlung die create mask und directory mask jeweils auf 0000 zu setzen und dann die gewünschten Rechte zu definieren (bei dir 0775).

create mask = 0000
force create mode = 0775
directory mask = 0000
force directory mode = 0775

Also ich habe das Tool (habe ich jetzt verstanden) auch installiert.

sudo getfacl /srv/dms/Test/Word6.doc

Die Ausgabe sieht wie folgt aus:

getfacl: Removing leading '/' from absolute path names
# file: srv/dms/Test/Word6.doc
# owner: dms
# group: dms
user::rwx
user:dms:rwx
group::rwx
group:dms:rwx
mask::rwx
other::r-x

Bei den Word-Dateien ohne + kommt da nur:

# owner: dms
# group: dms
user::rwx
group::rwx
other::r-x

Demnach steht in den ACLs von der Datei quasi gespiegelt nur an Rechten, was auf UNIX-Ebene festgelegt ist.

Die Einträge

   create mask = 0000
   force create mode = 0775
   directory mask = 0000
   force directory mode = 0775

haben nur den Effekt, dass bereits bei Erstellung der Datei die UNIX-Rechte anstelle von 764 diese auf 775 gesetzt sind. Das restliche Verhalten, also das Setzen des + bleibt.

Es ist kurios, jede andere Nicht-MS-Office-Datei, wie z.B. eine *.txt behält ihre Rechte (764) auch bei Änderungen und erhält nie das +

Nun, die Rechte werden ja über AND/OR u.a. auch mit den Angaben des Unix-Benutzers verknüpft. Da mag es sein, dass der Wert 764 eben Höchste ist was zugelassen ist. Ist es eine MS-Office-Datei gelten mit einem Mal andere Regeln, die Rechte werden auf 775 geändert und zusätzlich als ACL hinterlegt.

Die smb.conf Parameter, die das jegliche Ändern der Rechte durch den Client vor 4.0 verhindern konnten:

force security mode 
force directory security mode

sind gem. Doku jedoch nicht mehr verfügbar.

Ist das evt. ein leak? Also ich würde erwarten, dass sofern die Nutzung von ACLs nicht konfiguriert ist, dass derartige Änderungen von Client-Seite nicht möglich sein dürften. Denn keine ACLs im Einsatz sollte bedeuten auch keine Änderung der Rechte von Client-Seite möglich.

Hallo!

Kannst du mal folgendes testen (siehe hier):

   create mask = 0000
   force create mode = 0775
   directory mask = 0000
   force directory mode = 2775

yauu schrieb:

[…] Es ist kurios, jede andere Nicht-MS-Office-Datei, wie z.B. eine *.txt behält ihre Rechte (764) auch bei Änderungen und erhält nie das +

Was dafür spricht, dass dieser Effekt gar nichts mit Samba zu tun hat, sondern z.B. durch die Office-Software ausgelöst wird.

kB schrieb:

yauu schrieb:

[…] Es ist kurios, jede andere Nicht-MS-Office-Datei, wie z.B. eine *.txt behält ihre Rechte (764) auch bei Änderungen und erhält nie das +

Was dafür spricht, dass dieser Effekt gar nichts mit Samba zu tun hat, sondern z.B. durch die Office-Software ausgelöst wird.

Was den Auslöser anbetrifft, einverstanden. Aber das erklärt nicht, warum der Samba-Server dies erlaubt.

Es muss ein Konfigurationsfehler sein, der im Zusammenhang mit den wenigen vorgenommenen Einstellungen und der großen Zahl an Standartwerte zusammenhängt. Das andere, also ein leak wäre ja sicherlich längst aufgefallen. Das unbeabsichtigte Ändern von Rechten seitens des Clients sehe ich nicht als trivial an. Ich werde da so oder so weitersuchen müssen.

chr123 schrieb:

Hallo!

Kannst du mal folgendes testen (siehe hier):

   create mask = 0000
   force create mode = 0775
   directory mask = 0000
   force directory mode = 2775

Habe ich gemacht, der Effekt bleibt. MS-Office ändert die Rechte und setzt ACLs beim ersten Speichern via Word.

Es bleibt kurios bzw. mir ist das bisherige Verständnis für Samba-Freigaben unter der Version 4 irgendwie verloren gegangen. Ich habe einiges gelesen und letztlich das Problem behoben, es werden keine ACLs mehr zugelassen und es werden bereits mit ACLs versehende Office-Dokumente beim nochmaligen Anfassen "geheilt". Aber verstanden habe ich das nicht so richtig.

[global]
	add machine script = sudo /usr/sbin/useradd -N -g machines -c Machine -d /var/lib/samba -s /bin/false %u
	domain logons = Yes
	lanman auth = Yes
	log file = /var/log/samba/log.%m
	logging = file
	logon drive = P:
	logon script = logon.cmd
	map to guest = Bad User
	max log size = 1000
	ntlm auth = ntlmv1-permitted
	obey pam restrictions = Yes
	pam password change = Yes
	panic action = /usr/share/samba/panic-action %d
	passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
	passwd program = /usr/bin/passwd %u
	security = USER
	server min protocol = NT1
	server role = classic primary domain controller
	server string = %h server (Samba, Ubuntu)
	unix password sync = Yes
	usershare allow guests = Yes
	workgroup = MYDOMAIN
	idmap config * : backend = tdb
	inherit owner = windows and unix
	inherit permissions = Yes

[dms]
	comment = DMS
	force group = dms
	path = /srv/dms
	read only = No

Neu sind hier (mit testparm - in der smb.conf steht bei inherit owner = yes)

inherit owner = windows and unix
inherit permissions = Yes

Und weg sind sämtliche

create mask
force create mode

Option, usw. so als ob ACLs im Einsatz wäre. Sind Sie aber nicht.

Ich habe Zugriff via WindowsXP, Windows10 und Ubuntu eingeschränkt auf am Server autorisierte Benutzer. WindowsXP sogar mit PDC (ist nur historisch, macht nicht mehr wirklich viel Sinn). Ich kann mit Hilfe von UNIX-Gruppen bzw. die Zuordnung den Zugriff auf bestimmte Verzeichnisse für bestimmte Benutzer einschränken. Alle Dateien und Verzeichnisse sind ungeachtet dessen gleichmäßig mit Rechten und Eigner einheitlich versehen.

Bleibt nun abzuwarten, ob nicht doch irgendein anderes Problem auftritt.

Hallo!

Die Parameter inherit owner und inherit permissions gelten nur für die Shares und gehören nicht in die globale Sektion.

chr123 schrieb:

Hallo!

Die Parameter inherit owner und inherit permissions gelten nur für die Shares und gehören nicht in die globale Sektion.

Danke für den Hinweis. Offensichtlich ändert dieser Eintrag in [global] das Standardverhalten von Samba für sämtliche shares, wo dann keine weiteren Angaben gemacht werden müssen.

Diese neue Optionen scheinen im Zusammenhang mit ACLs zu stehen. Da auf meinem Server die Nutzung von ACLs ausdrücklich nicht vorgesehen ist, und zwar egal welches share, entfaltet diese Optionen unter [global] das gewünschte Verhalten, nämlich jegliches unerwünschtes Ändern der Rechte einschl. ACLs durch den jeweiligen Client zu unterbinden. Diese "Anti-ACL-Kombination" an Optionen bereinigt sogar bereits fehlerhaft zugewiesene ACLs. Ich belasse es damit vorerst in [global]. Die Dokumentation gibt in dieser Hinsicht keine weitergehende Dokumentation her.

Wie schon geschrieben, mein bisheriges Verständnis der Samba-Konfiguration ohne ACL hat sowieso schon Schaden genommen. Bisher habe ich noch kein unerwünschtes Verhalten wie zuvor konfiguriert feststellen können, und gerade mit Blick auf die Sicherheit zählt dies. Denn wenn MS-Office in der Lage ist, hier ohne ausreichende Konfiguration Rechte und ACLS zu ändern, warum nicht eine Datei auf einem home-share mit SUID versehen?