Hi all,
also mit Linux-Permissions (users, group, others) kenn ich mich soweit aus (wird ja auch Zeit nach 50 Jahren :-) )
Nun habe ich ein OpenMediaVault 6 am Start wo aus unerfindlichen Gründen das System nochmal mit einer zweiten Schicht an Permissions rumfummelt, die ich mit "getfacl" - "setfacl" erreichen kann und die wiedersprechen sich bei einer Installation. Ich hab da aber nie bewußt eine "zweite Schicht Permissions" bestellt... wozu auch?
In kurz: Wie werde ich diese zweite Permissionebene am liebsten komplett los oder wenn das nicht geht wie setze ich sie alle auf die Linux-Daten?
Gelten soll was im Unix-Filesystem steht für user, groups und die ugo - Permissions.
Welche Einstellung in Samba oder OMV unterbindet das für die Zukunft?
Vielen Dank for any hints!
On Tue, Aug 12, 2025 at 04:37:52PM +0200, Andreas Delleske wrote:
Hi all,
also mit Linux-Permissions (users, group, others) kenn ich mich soweit aus (wird ja auch Zeit nach 50 Jahren :-) )
Nun habe ich ein OpenMediaVault 6 am Start wo aus unerfindlichen Gründen das System nochmal mit einer zweiten Schicht an Permissions rumfummelt, die ich mit "getfacl" - "setfacl" erreichen kann und die wiedersprechen sich bei einer Installation. Ich hab da aber nie bewußt eine "zweite Schicht Permissions" bestellt... wozu auch?
Möglicherweise (?) ist da gar keine andere Schicht, sondern nur eine bombastische Benamsung dessen, was Du schon kennst.
In kurz: Wie werde ich diese zweite Permissionebene am liebsten komplett los oder wenn das nicht geht wie setze ich sie alle auf die Linux-Daten?
Gelten soll was im Unix-Filesystem steht für user, groups und die ugo - Permissions.
Bei mir (ich habe keine extended ACLs), irgend eine random-Datei (ich weiss, ich weiss, ich sollte mein ~/ aufräumen):
tomas@caliban:~$ ls -l hash-vs-alist.el -rw-r--r-- 1 tomas tomas 729 Dec 26 2024 hash-vs-alist.el
und
tomas@caliban:~$ getfacl hash-vs-alist.el # file: hash-vs-alist.el # owner: tomas # group: tomas user::rw- group::r-- other::r--
Wenn ich man(1) getfacl mache, dann verstehe ich auch so viel. Die eine sagt "Lok", der andere "Triebwagen". Die von uns allen geliebten ugo sind bereits ACLs. Minimalistisch halt.
Vermutlich ist das getfacl/setfacl-Interface darauf ausgelegt, auch mit ausgeklügelteren Zugriffsrechtsbürokratien klarzukommen. Dein Dateisystem muss aber nicht jeden Mist mitmachen.
Aber vielleicht... ext4 kann extended attributes, da kann mensch gerüchteweise weiterführende ACLs unterbringen, aber Du brauchst dann auch die Polizeikräfte, die das durchsetzen: hast Du SELinux, oder vllt. AppDingens am laufen? Was passiert, wenn Du auf eine Deiner Dateien "getacl" loslässt?
lg
Hallo Tomas,
On 8/12/25 17:07, tomas@tuxteam.de wrote:
On Tue, Aug 12, 2025 at 04:37:52PM +0200, Andreas Delleske wrote:
also mit Linux-Permissions (users, group, others) kenn ich mich soweit aus (wird ja auch Zeit nach 50 Jahren :-) )
Nun habe ich ein OpenMediaVault 6 am Start wo aus unerfindlichen Gründen das System nochmal mit einer zweiten Schicht an Permissions rumfummelt, die ich mit "getfacl" - "setfacl" erreichen kann und die wiedersprechen sich bei einer Installation. Ich hab da aber nie bewußt eine "zweite Schicht Permissions" bestellt... wozu auch?
Möglicherweise (?) ist da gar keine andere Schicht, sondern nur eine bombastische Benamsung dessen, was Du schon kennst.
Es gibt ein Mapping der traditionellen ugo-Bits in das Modell von {g,s}etfacl, aber nicht umgekehrt. In ersterem kannst Du nur die Rechte für einen Benutzer und eine Gruppe festlegen, mit {g,s}etfacl für beliebige Nutzer und Gruppen.
Aber vielleicht... ext4 kann extended attributes, da kann mensch gerüchteweise weiterführende ACLs unterbringen, aber Du brauchst dann auch die Polizeikräfte, die das durchsetzen: hast Du SELinux, oder vllt. AppDingens am laufen? Was passiert, wenn Du auf eine Deiner Dateien "getacl" loslässt?
Für die Zugriffsrechte, die mit {g,s}etfacl abgefragt und gesetzt werden, braucht man kein LSM wie SELinux oder Apparmor. Das funktioniert einfach so.
Liebe Grüße Uwe
On Wed, Aug 20, 2025 at 04:03:53PM +0200, Uwe Kleine-König wrote:
Hallo Tomas,
On 8/12/25 17:07, tomas@tuxteam.de wrote:
On Tue, Aug 12, 2025 at 04:37:52PM +0200, Andreas Delleske wrote:
also mit Linux-Permissions (users, group, others) kenn ich mich soweit aus (wird ja auch Zeit nach 50 Jahren :-) )
Nun habe ich ein OpenMediaVault 6 am Start wo aus unerfindlichen Gründen das System nochmal mit einer zweiten Schicht an Permissions rumfummelt, die ich mit "getfacl" - "setfacl" erreichen kann und die wiedersprechen sich bei einer Installation. Ich hab da aber nie bewußt eine "zweite Schicht Permissions" bestellt... wozu auch?
Möglicherweise (?) ist da gar keine andere Schicht, sondern nur eine bombastische Benamsung dessen, was Du schon kennst.
Es gibt ein Mapping der traditionellen ugo-Bits in das Modell von {g,s}etfacl, aber nicht umgekehrt. In ersterem kannst Du nur die Rechte für einen Benutzer und eine Gruppe festlegen, mit {g,s}etfacl für beliebige Nutzer und Gruppen.
So etwas meinte ich...
Aber vielleicht... ext4 kann extended attributes, da kann mensch gerüchteweise weiterführende ACLs unterbringen, aber Du brauchst dann auch die Polizeikräfte, die das durchsetzen: hast Du SELinux, oder vllt. AppDingens am laufen? Was passiert, wenn Du auf eine Deiner Dateien "getacl" loslässt?
Für die Zugriffsrechte, die mit {g,s}etfacl abgefragt und gesetzt werden, braucht man kein LSM wie SELinux oder Apparmor. Das funktioniert einfach so.
Ich verlor den Kontext: ich war in "nur Linux" -- da braucht es doch einen Teil, der die ACLs (jenseits der "traditionellen") durchsetzt, wenn sie nicht "nur auf der Platte herumliegen" sollen. In diesem Fall ist's wohl der (Windows?) Client, verstehe ich das richtig? Bei "nur Linux" bräuchte es dazu irgend ein LSM, das diese erweiterten ACLs liest und durchsetzt.
lg
Am Mittwoch, August 20, 2025 17:44 CEST, schrieb tomas@tuxteam.de:
Ich verlor den Kontext: ich war in "nur Linux" -- da braucht es doch einen Teil, der die ACLs (jenseits der "traditionellen") durchsetzt, wenn sie nicht "nur auf der Platte herumliegen" sollen.
Nein, soweit mir bekannt braucht's nichts weiteres. Man kann mit 'setfacl -m u:username:r datei' einem weiteren Nutzer Leserechte geben. Dier darf ab dann die Datei lesen, auch wenn die Unix-Permissions (ugo) das nicht erlauben.
Gruss RalfD
In diesem Fall ist's wohl der (Windows?) Client, verstehe ich das richtig? Bei "nur Linux" bräuchte es dazu irgend ein LSM, das diese erweiterten ACLs liest und durchsetzt.
lg
t
On Wed, Aug 20, 2025 at 07:47:34PM +0200, Ralf Mattes wrote:
Am Mittwoch, August 20, 2025 17:44 CEST, schrieb tomas@tuxteam.de:
Ich verlor den Kontext: ich war in "nur Linux" -- da braucht es doch einen Teil, der die ACLs (jenseits der "traditionellen") durchsetzt, wenn sie nicht "nur auf der Platte herumliegen" sollen.
Nein, soweit mir bekannt braucht's nichts weiteres. Man kann mit 'setfacl -m u:username:r datei' einem weiteren Nutzer Leserechte geben. Dier darf ab dann die Datei lesen, auch wenn die Unix-Permissions (ugo) das nicht erlauben.
Tatsächlich. Wieder was gelernt -- danke :)
lg
Hallo,
Wenn Windows via Samba auf ein Linux-Dateisystem zugreift, werden die on Windows-Nutzern gesetzten Rechte in Linux in ACLs und Extended Attributes gespeichert.
Die Zugriffsrechte dieser Dateien sollte man aus Linux heraus nicht anfassen, denn dabei gehen die von Windows gesetzten Rechte kaputt.
Klaus
-
Andreas Delleske -
Klaus Hartnegg -
Olav Seyfarth -
Ralf Mattes -
tomas＠tuxteam.de -
Uwe Kleine-König