staging.inyokaproject.org

kB schrieb:

So sieht das bei mir aus:

$ ls -al /dev/sda2 /media/Windows /bin/ntfs-3g
-rwsr-xr-x 1 root root 162704 Nov  1  2022 /bin/ntfs-3g
brw-rw-rw- 1 root disk   8, 2 Mär 19 20:05 /dev/sda2

/media/Windows:
insgesamt 8
drwxrwxrwx 2 root root 4096 Mär 19 19:53 .
drwxr-xr-x 4 root root 4096 Mär 19 19:53 ..
$ grep ntfs /etc/fstab 
#/dev/sda2					/media/Windows	ntfs-3g noauto,rw,users	0 0
/dev/sda2					/media/Windows	ntfs-3g noauto,rw		0 0
klaus@ubuntu-test:~/Schreibtisch$ mount -v /media/Windows/ ; echo $?
mount: /media/Windows: die Operation kann nur vom Benutzer root ausgeführt werden.
1
$

$ grep ntfs /etc/fstab 
/dev/sda2					/media/Windows	ntfs-3g noauto,rw,users	0 0
#/dev/sda2					/media/Windows	ntfs-3g noauto,rw		0 0
$ mount -v /media/Windows/ ; echo $?
0
$ findmnt -t fuseblk
TARGET         SOURCE    FSTYPE  OPTIONS
/media/Windows /dev/sda2 fuseblk rw,nosuid,nodev,noexec,relatime,user_id=1000,group_id=1000,allow_other,blksize=4096
$ 

Ich hab' das jetzt auch mal ohne defaults ausprobiert. Bei mir bindet mount dann immer noch ohne users ein. Allerdings fehlt dann bei mir noexec. Aber auch, wenn ich das manuell hinzufüge, klappt mount immer noch. Ob das evtl. daran liegt, dass ich noch den LTS-Kernel 5.15 verwende ???

ich@T500:~$ sudo chmod u+s /usr/bin/ntfs-3g
ich@T500:~$ sudo chmod 777 /media/Sicherung
ich@T500:~$ sudo chmod 666 /dev/sda7
ich@T500:~$ sudoedit /etc/fstab
ich@T500:~$ cat /etc/fstab | grep Sicherung
# /media/Sicherung was on /dev/sda7 during installation
UUID=2510AA16624BB80C   /media/Sicherung        ntfs    rw,noauto,windows_names,hide_dot_files      0       0
ich@T500:~$ mount -v /media/Sicherung
ich@T500:~$ echo $?
0
ich@T500:~$ mount | grep Sicherung
/dev/sda7 on /media/Sicherung type fuseblk (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,allow_other,blksize=4096)
ich@T500:~$ umount /media/Sicherung
ich@T500:~$ sudoedit /etc/fstab
ich@T500:~$ cat /etc/fstab | grep Sicherung
# /media/Sicherung was on /dev/sda7 during installation
UUID=2510AA16624BB80C   /media/Sicherung        ntfs    noexec,rw,noauto,windows_names,hide_dot_files      0       0
ich@T500:~$ mount -v /media/Sicherung
ich@T500:~$ echo $?
0
ich@T500:~$ mount | grep Sicherung
/dev/sda7 on /media/Sicherung type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=1000,group_id=1000,allow_other,blksize=4096)
ich@T500:~$ umount /media/Sicherung
ich@T500:~$ 

UlfZibis schrieb:

[…] Ich hab' das jetzt auch mal ohne defaults ausprobiert. Bei mir bindet mount dann immer noch ohne users ein.

Das ist dann nicht regelgerecht. Außer, Du verwendest ein anderes mount als ich. Ich verwende das standardmäßig in Ubuntu enthaltene:

$ type mount
mount ist gehasht (/usr/bin/mount)
$ mount -V
mount aus util-linux 2.34 (libmount 2.34.0: selinux, smack, btrfs, namespaces, assert, debug)
$ 

Was ergibt das bei Dir?

Oder Du bist auf eine hinterhältig verkappte Art doch root.

Allerdings fehlt dann bei mir noexec.

Was wiederum regelgerecht ist, weil die Option users ja die Optionen noexec,nodev,nosuid setzt.

Aber auch, wenn ich das manuell hinzufüge, klappt mount immer noch. Ob das evtl. daran liegt, dass ich noch den LTS-Kernel 5.15 verwende ??? […]

Den benutze ich auch und habe ein regelgerechtes Verhalten von mount, d.h.:

• mount als nicht-root und ohne user ⇒ Fehlermeldung „die Operation kann nur vom Benutzer root ausgeführt werden.“ und Ergebnis 1 (=Fehler)

kB schrieb:

$ mount -V
mount aus util-linux 2.34 (libmount 2.34.0: selinux, smack, btrfs, namespaces, assert, debug)

Das ist ja sehr interessant, vielleicht des Pudels Kern.

$ mount -V
mount aus util-linux 2.37.2 (libmount 2.37.2: selinux, smack, btrfs, verity, namespaces, assert, debug)
$ type mount
mount ist gehasht (/usr/bin/mount)
$ apt policy mount
mount:
  Installiert:           2.37.2-4ubuntu3
  Installationskandidat: 2.37.2-4ubuntu3
  Versionstabelle:
 *** 2.37.2-4ubuntu3 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        100 /var/lib/dpkg/status

Oder Du bist auf eine hinterhältig verkappte Art doch root.

Wer weiß ???

Allerdings fehlt dann bei mir noexec.

Was wiederum regelgerecht ist, weil die Option users ja die Optionen noexec,nodev,nosuid setzt.

Ja bei Dir ist das noch regelgerecht, in meiner Version wohl nicht mehr.

Wie kommt es, dass da bei Dir noch die ältere Version von mount installiert ist?

Oder Du bist auf eine hinterhältig verkappte Art doch root.

So kommt es mir auch vor. Aber ich blicke da, wie schon öfters gesagt, nicht mehr durch.

Ich möchte jetzt gerne auf 2 Schienen weiterfahren:

1. Die Diskussion ist sehr interessant und lehrreich, und die möchte ich natürlich keineswegs "abwürgen".

2. Ich verspüre ein großes Bedürfnis, für das Wiki nun endlich mit NTFS-3G fertig zu werden.

für 2. möchte ich vorschlagen: Wir beschränken uns auf das Verhalten von NTFS-3G, wenn die "NTFS-G-Bedingungen" Default-Werte haben und nicht von Hand verändert wurden. Wenn das Verhalten dann unerklärlich ist, dann akzeptieren wir das eben als gegeben und schreiben, was man dann machen kann. Möglichst einfach und pragmatisch und möglichst ohne gefährliche "Winkelzüge" wie das Ändern von Dateirechten in /dev. Sonst kommen wir zu keinem Ende. Und es gibt dann ja auch noch den Kernel-Treiber NTFS3, sicher mit weiteren Überraschungen.

Nichts desto trotz möchte ich jetzt noch ein bisschen auf Schiene 1. weiterfahren…

Macht dabei users einen Unterschied?

(bei udisksctl -b und exfat-fuse) Soviel ich mich erinnere nicht. Ich will mir aber sicherheitshalber exfat-fuse nochmal vorknöpfen.

Ich will keineswegs behaupten, dass ich da durchblicke (s.o.). Trotzdem will ich es wagen, "ins Unreine" ’mal eine Spekulation zu äußern:

• NTFS-3G kennt eine riesige Anzahl von Optionen, die aufzuzählen mein armes Gedächtnis überfordert. Darunter sind welche, die auch die Dateirechte betreffen wie z.B. inherit, und die sich bestimmt nicht ohne "verkappte" Root-Rechte realisieren lassen.

• NTFS-3G richtet im Gegensatz zu NTFS3 keine eigene Rechteverwaltung ein, sondern verwendet diejenige von Windows und bildet hierzu mittels User-Mapping die gesamte Linux-Rechteverwaltung umkehrbar eindeutig auf die Rechteverwaltung von Windows ab. Für die UNIX-Dateirechte geht das offenbar in der Richtung Linux nach Windows problemlos (?), für die POSIX-ACL und auch für Windows nach Linux nur mit gewissen Einschränkungen. Was dafür "gewurschtelt" werden muss, weiß ich nicht. Ich kann mir vorstellen, dass dies nicht ganz einfach ist. An welchen "Schrauben" da gedreht wird, weiß ich nicht.

• Der Treiber exfat-fuse kennt natürlich alle diese Probleme nicht und kann deshalb viel leichter "regelgerecht" bleiben.

Zurück auf Schiene 2.: Für user(s) würde ich nun folgende (faule?) pragmatische Lösung vorschlagen:

Zu "unvorhergesehenen Reaktionen" gehört, dass man sie eben nicht genauer angeben und erklären kann. – Ich meine jedenfalls, dass ich damit leben könnte.

Nach dem "Einbinden" möchte ich mich nun gerne dem eigentlichen "Knackpunkt" von NTFS-3G, dem User-Mapping zuwenden. Die bisherige Darstellung im Artikel ist weder verständlich noch vollständig.

L.G.

Max-Ulrich_Farber schrieb:

@UlfZibis:

Hattest Du denn für den Benutzer auch Lese und Schreibrechte für Gerätedatei und den Einbindepunkt hergestellt, also die vollständigen "FUSE-Bedingungen"?

Nein, das hatte ich nicht. An den Dateirechten in /dev schraube ich nicht so gerne herum. Ich gehe fürs Wiki davon aus, dass diese default belassen sind. ... Und da ist die Sache IMO ziemlich klar: Finger weg von user(s) bei NTFS-3G!. Basta.

Ich kann Deine Beobachtung - wie von Dir beschrieben - so bestätigen und schließe mich Deinem pragmatischen Fazit ebenfalls an.

Ich sehe auch kein Schaden für Nutzer, die ihr System hinsichtlich ntfs-3g-Einhänge-Bedingungen in der Vergangenheit "zurechtgebogen" haben, denn die sind von dem udisks-Fehler nach meiner Beobachtung nicht betroffen.

Wer aber neu an die Sache herangeht, der sollte auf Basis von udisks konfigurieren und das bedeutet im Moment, ab Ubuntu 22.04 auf die Optionen user(s) in der /etc/fstab zu verzichten.

@ Newubunti:

Also: Genehmigt. Aber eben als Ausnahme. Aber bitte nicht so darstellen, wie wenn dies ein ganz normales Recht des Unprivilegierten wäre. So ist es dann doch auch nicht.

Mein Vorschlag dazu ist wie oben erwähnt:

Versuchen Benutzer die nicht der Gruppe sudo angehören, NTFS-Partitionen mittels z.B. Nautils oder Laufwerke einzuhängen, so werden sie beim Versuch des Einhängens per GUI unter Umständen nach dem Passwort des Systemverwalters gefragt. Soll die betreffende Partition ohne diese Passwortabfrage eingebunden werden können, so ist das notwendige Vorgehen in udisks2 beschrieben.

LG, Newubunti

Ich stimme in allen diesen Punkten mit Newubunti überein. 😀

Sollten wir dann nicht, falls wir der "pragmatischen" Lösung zustimmen (?), die weitere Diskussion des users und Root-Problems bei NTFS-3G vom Wiki abkoppeln und in einen andern Thread übernehmen? Denn da könnten bestimmt noch einige interessante, fürs Wiki aber nicht mehr relevante Aspekte auftauchen. Und dieser Thread hier ist wahrhaftig schon lang genug und bereits ziemlich unübersichtlich geworden. – Das ist nur ein Vorschlag des "Themenstarters".

Newubunti, könntest Du dann bitte den Artikel bis hin zu Standard-Einstellungen in deinem Sinne nochmal überarbeiten. Dann mache ich da weiter. Von da ab stimmt ja leider manches auch nicht (mehr).

UlfZibis schrieb:

[…]

$ mount -V
mount aus util-linux 2.37.2 (libmount 2.37.2: selinux, smack, btrfs, verity, namespaces, assert, debug)
$ type mount
mount ist gehasht (/usr/bin/mount)
$ apt policy mount
mount:
  Installiert:           2.37.2-4ubuntu3
  Installationskandidat: 2.37.2-4ubuntu3
  Versionstabelle:
 *** 2.37.2-4ubuntu3 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        100 /var/lib/dpkg/status

[…]

Was wiederum regelgerecht ist, weil die Option users ja die Optionen noexec,nodev,nosuid setzt.

Ja bei Dir ist das noch regelgerecht, in meiner Version wohl nicht mehr.

Die Beschreibung der Option user ist bei Version 2.34 und 2.37 gleich.

Wie kommt es, dass da bei Dir noch die ältere Version von mount installiert ist?

Bei 20.04 HWE mit Kernel 5.15 ist Version 2.34 von mount aktuell und bei 22.04 LTS mit Kernel 5.15 ist Version 2.37 von mount aktuell.

Bei einem 22.04-System beobachte ich auch das von Dir beschriebene Verhalten: mount arbeitet auch mit ntfs-3g beim Aufruf durch einen normalen Benutzer ohne Option user in der fstab.

Das hat mich höchst überrascht, da wider alle als sicher geglaubte Lehre.

Die Manpage von mount (2.37) sagt dazu im Abschnitt "Non-superuser mounts":

Since util-linux 2.35, mount does not exit when user permissions are inadequate according to libmount’s internal security rules. Instead, it drops suid permissions and continues as regular non-root user. This behavior supports use-cases where root permissions are not necessary (e.g., fuse filesystems, user namespaces, etc).

Damit ist alles klar: Sowohl Dein wie mein beobachtetes Verhalten ist jeweils völlig regelgerecht, nur ändern sich die Regeln mit der Zeit bzw. der Version.

• Früher: mount als normaler Benutzer benötigt user, dafür benötigt das aufgerufene FUSE-Programm kein SUID. Im Falle von ntfs-3g aber doch, was an diesem liegen mag.

• Jetzt: mount als normaler Benutzer benötigt user nicht mehr, dann ruft es aber das benötigte FUSE-Programm als normaler Benutzer auf und deshalb benötigt dieses nun erst recht SUID.

Also alles regelgerecht, allerdings schreibt die Regeln Altmeister Kafka nach Metaregeln, die er wohl selbst nicht kennt.

Wenigstens entfällt hierdurch jede Motivation, in der fstab user zu notieren. Außer bei 20.04. Außer bei Kernel-Modulen. Außer in den Fällen, in denen es sonst nicht funktioniert.

Max-Ulrich_Farber schrieb:

für 2. möchte ich vorschlagen: Wir beschränken uns auf das Verhalten von NTFS-3G, wenn die "NTFS-G-Bedingungen" Default-Werte haben und nicht von Hand verändert wurden.

Sehr gut! Auch die Verwendung der Sammel-Option defaults in der fstab sollte IMHO als Standard unterstellt werden. Und wenn mount sich unter diesen Default-Bedingungen nicht konform zu mount verhält, sollte dies mindestens als nicht regelkonform und IMHO als Bug betrachtet werden. Deshalb möchte ich nochmal anregen, den Bug (auch wenn er nicht perfekt formuliert ist) auch von anderer Seite mit "affects me" zu markieren, damit er den Status "Confirmed" erhält, und dadurch die Chance gegeben ist, dass seitens Ubuntu "des Pudels Kern" wenigstens mal erläutert oder gar gefixt wird.

• NTFS-3G richtet im Gegensatz zu NTFS3 keine eigene Rechteverwaltung ein, sondern verwendet diejenige von Windows und bildet hierzu mittels User-Mapping die gesamte Linux-Rechteverwaltung umkehrbar eindeutig auf die Rechteverwaltung von Windows ab.

Zu 100 % stimmt das leider auch nicht. So gelingt z.B. kein funktionierendes Mapping zwischen dem Windows-Ordner "Public" und dem Ubuntu-Ordner "Öffentlich". Ich hab' da damals mit dem Entwickler Jean-Pierre André wochenlang drüber diskutiert.

Und dann ist da noch die leider nicht kompatible Transformation von Sym-Links.

Zurück auf Schiene 2.: Für user(s) würde ich nun folgende (faule?) pragmatische Lösung vorschlagen:

Hinweis:

NTFS-3G unterstützt die Optionen user und users nicht. Werden diese trotzdem verwendet, so kann dies zu unvorhergesehenen Reaktionen führen. Deshalb sollte man unbedingt bei NTFS-3G diese Optionen vermeiden

Sehr gut! Vielleicht noch eine kleine Verbesserung:

... die mount-Optionen user und users nicht regelkonform.

So kann der Artikel erst mal abgeschlossen werden, bis weitere Erkenntnisse vorliegen.

Nach dem "Einbinden" möchte ich mich nun gerne dem eigentlichen "Knackpunkt" von NTFS-3G, dem User-Mapping zuwenden. Die bisherige Darstellung im Artikel ist weder verständlich noch vollständig.

Dazu der Hinweis: Das User-Mapping funktioniert nur "vollständig" für ein Windows- <=> Linux-Benutzer-Mapping. Für mehrere Benutzer gibt's da eine konzeptbedingte Barriere. Auch darüber habe ich damals wochenlang mit dem Entwickler diskutiert und eine Konzept-Erweiterung präsentiert, leider erfolglos. Ein Patch dazu steht immer noch auf meiner ToDo-Liste.

Newubunti schrieb:

Ich kann Deine Beobachtung - wie von Dir beschrieben - so bestätigen und schließe mich Deinem pragmatischen Fazit ebenfalls an.

Ich sehe auch kein Schaden für Nutzer, die ihr System hinsichtlich ntfs-3g-Einhänge-Bedingungen in der Vergangenheit "zurechtgebogen" haben, denn die sind von dem udisks-Fehler nach meiner Beobachtung nicht betroffen.

Wer aber neu an die Sache herangeht, der sollte auf Basis von udisks konfigurieren und das bedeutet im Moment, ab Ubuntu 22.04 auf die Optionen user(s) in der /etc/fstab zu verzichten.

Volle Zustimmung ❗

Versuchen Benutzer die nicht der Gruppe sudo angehören, NTFS-Partitionen mittels z.B. Nautils oder Laufwerke einzuhängen, so werden sie beim Versuch des Einhängens per GUI unter Umständen nach dem Passwort des Systemverwalters gefragt. Soll die betreffende Partition ohne diese Passwortabfrage eingebunden werden können, so ist das notwendige Vorgehen in udisks2 beschrieben.

Auch perfekt bis auf den Tippfehler.

Max-Ulrich_Farber schrieb:

[…] Für user(s) würde ich nun folgende (faule?) pragmatische Lösung vorschlagen:

Hinweis:

NTFS-3G unterstützt die Optionen user und users nicht. Werden diese trotzdem verwendet, so kann dies zu unvorhergesehenen Reaktionen führen. Deshalb sollte man unbedingt bei NTFS-3G diese Optionen vermeiden

Zu "unvorhergesehenen Reaktionen" gehört, dass man sie eben nicht genauer angeben und erklären kann. – Ich meine jedenfalls, dass ich damit leben könnte.

Hinsichtlich Ziel und Vorgehen stimme ich uneingechränkt zu. Die Formulierung des Hinweises bedarf noch Feinschliff.

Mein Vorschlag:

• Bei NTFS-3G ergeben sich im Zusammenhang mit den eigentlich nur für das Programm mount relevanten Optionen nouser,user,users manchmal Komplikationen und Fehlfunktion bis hin zum Scheitern. Eine Verwendung dieser Optionen wird widerraten zu Gunsten der Methoden, welche diese Optionen nicht benötigen.

Max-Ulrich_Farber schrieb:

Sollten wir dann nicht, falls wir der "pragmatischen" Lösung zustimmen (?), die weitere Diskussion des users und Root-Problems bei NTFS-3G vom Wiki abkoppeln und in einen andern Thread übernehmen?

Von meiner Seite ist das Thema nun jedoch (fast) abgeschlossen.

Hinsichtlich Ziel und Vorgehen stimme ich uneingechränkt zu.

Dann sind wir uns ja im Grunde alle einig! Auf so viel Zustimmung zu hoffen hatte ich ja kaum mehr gewagt.

Die Formulierung des Hinweises bedarf noch Feinschliff.

Das kommt dann noch. Aber schleift mir bitte keine neuen Furchen ’rein! – Der Inhalt ist jedenfalls klar.

zum User-Mapping:

bildet hierzu mittels User-Mapping die gesamte Linux-Rechteverwaltung umkehrbar eindeutig auf die Rechteverwaltung von Windows ab.

Das ist von mir missverständlich formuliert. Dies ist die Absicht, und hinsichtlich der realen Verwirklichung bringen schon die beiden darauf folgenden Sätzchen eine Einschränkung:

Für die UNIX-Dateirechte geht das offenbar in der Richtung Linux nach Windows problemlos (?), für die POSIX-ACL und auch für Windows nach Linux nur mit gewissen Einschränkungen.

Die Absicht lässt sich halt nicht vollkommen verwirklichen.

kB schrieb:

Bei 20.04 HWE mit Kernel 5.15 ist Version 2.34 von mount aktuell und bei 22.04 LTS mit Kernel 5.15 ist Version 2.37 von mount aktuell.

Ach Deine Tests hattest Du mit 20.04 gemacht (So hast Du mich aber echt lange "an der Nase herum geführt"). Das bestätigt ja dann meine Behauptung, dass sich da mount noch (eher) regelkonform verhalten hat. Deshalb ist mein Bug-Report ja auch mit "REGRESSION" betitelt.

Bei einem 22.04-System beobachte ich auch das von Dir beschriebene Verhalten: mount arbeitet auch mit ntfs-3g beim Aufruf durch einen normalen Benutzer ohne Option user in der fstab.

Na endlich !

Das hat mich höchst überrascht, da wider alle als sicher geglaubte Lehre.

So ging es mir eben auch 🐸

Die Manpage von mount (2.37) sagt dazu im Abschnitt "Non-superuser mounts":

Since util-linux 2.35, mount does not exit when user permissions are inadequate according to libmount’s internal security rules. Instead, it drops suid permissions and continues as regular non-root user. This behavior supports use-cases where root permissions are not necessary (e.g., fuse filesystems, user namespaces, etc).

Äußerst ungeschickt, diesen Hinweis nicht mit den Optionen (no)user(s) zu verlinken. ☹ Gratulation Deinem Fund. 👍
Aber dennoch schwer verstehbar. Ich würde daraus schließen, dass damit die berühmten "FUSE-Bedingungen" aufgehoben sind.

Damit ist alles klar: Sowohl Dein wie mein beobachtetes Verhalten ist jeweils völlig regelgerecht, nur ändern sich die Regeln mit der Zeit bzw. der Version.

Nicht völlig, denn das fehlerbehaftete Verhalten mit UDisks ist ja auch noch da. Oder hast Du dafür auch noch eine regelkomforme Erklärung?

• Früher: mount als normaler Benutzer benötigt user, dafür benötigt das aufgerufene FUSE-Programm kein SUID. Im Falle von ntfs-3g aber doch, was an diesem liegen mag.

Somit ist NTFS-3G also nicht mehr "up to date". Könnte man das kurz und knapp im Artikel vermerken?

• Jetzt: mount als normaler Benutzer benötigt user nicht mehr, dann ruft es aber das benötigte FUSE-Programm als normaler Benutzer auf und deshalb benötigt dieses nun erst recht SUID.

... und die nötigen Rechte an Gerätedatei und Einbindepunkt. Diese kann man dann z.B. durch Hinzufügen des normalen Benutzers in die Gruppe disk herstellen, was aber nicht ungefährlich ist. Evtl. helfen da auch irgendwelche Policy- oder UDisks-Regeln.

Also alles regelgerecht, allerdings schreibt die Regeln Altmeister Kafka nach Metaregeln, die er wohl selbst nicht kennt.

😀

Wenigstens entfällt hierdurch jede Motivation, in der fstab user zu notieren. Außer bei 20.04. Außer bei Kernel-Modulen. Außer in den Fällen, in denen es sonst nicht funktioniert.

Die Optionen user(s) sind also nur noch für Kernel-Module zu gebrauchen. Dass wäre doch einen Hinweis im mount-Artikel wert, also: "Seit 22.04 ..."

Max-Ulrich_Farber schrieb:

zum User-Mapping:

bildet hierzu mittels User-Mapping die gesamte Linux-Rechteverwaltung umkehrbar eindeutig auf die Rechteverwaltung von Windows ab.

Das ist von mir missverständlich formuliert. Dies ist die Absicht, ...

OK !

Für die UNIX-Dateirechte geht das offenbar in der Richtung Linux nach Windows problemlos (?),

Sobald mehr als ein Benutzer gemappt wird, ist auch diese Richtung "problematisch".

Sobald mehr als ein Benutzer gemappt wird, ist auch diese Richtung "problematisch".

deshalb auch "(?)". Ich hätte auch schreiben können "angeblich".

Doch nun zu meiner Zusage, exfat-fuse nochmal unter die Lupe zu nehmen:

Alles IMO völlig "normal".

Das heißt:

• sudo mount funktioniert mit Standard-Einstellungen /dev/… und /media/<Mountpunkt>, mit oder ohne users. SUID-Bit spielt dabei natürlich keine Rolle.

• mount ohne Root-Rechte funktioniert nur mit angepassten Rechten für /media/<Mountpunkt> (trivial), nicht für /dev/…, sowie users und SUID-Bit für /usr/sbin/mount.exfat-fuse. Eigentümer der Dateien ist nach wie vor root:root, Maske 0000 (Modus 0777). Fehlt das SUID-Bit, kommt folgende Fehlermeldung:

  fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf

• udisksctl mount -b… funktioniert ungeachtet aller Bedingungen (auch users) ohne und auch mit sudo. Eigentümer der Dateien ist der einbindende Benutzer ("ich" oder Root), Maske lokales umask.

So sollte es IMO auch bei NTFS-3G sein. Ich will noch überprüfen, wie sich user_allow_other auswirkt, aber ich vermute, gleich wie das SUID-Bit.

EDIT

user_allow_other ersetzt nicht ohne weiteres das SUID-Bit: Fehlermeldung

fusermount: unknown option 'user=farber'

Ich habe da nicht weitergemacht.