staging.inyokaproject.org

Max-Ulrich_Farber schrieb:

Es kann ja nur ein Verhalten bezüglich des Einbindens "regelgerecht" sein. Entweder das von exfat-fuse oder das von ntfs-3g.

👍

Was ist regelgerecht, und was nicht. Das ist bei mir ein Verständnisproblem, das mich beschäftigt.

Meinem Verständnis nach verhält sich exfat-fuse bzgl. users regelgerecht = verhält sich so, wie in mount beschrieben.

mount hat sich mit NTFS-3G noch nie regelgerecht verhalten.
udisksctl mount hat sich mit NTFS-3G zumindest bis 20.04 regelgerecht verhalten.

dann braucht man den IMO nicht - weil praktisch ist der nicht in vertretbarer Weise nutzbar.

Das ist genau, was ich sage. Also sind wir uns da völlig einig.

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.

Und das kommt eben, soviel ich jetzt weiß, standardmäßig nur bei internen Partitionen vor, weil bei diesen und nur bei diesen standardmäßig hintsystem=yes gilt. Und diese sollten ja unprivilegierte User eben gar nicht einhängen können. Das ist doch, wie ich es verstanden habe, der Sinn des hintsystem, einen anderen sehe ich nicht. Nochmal ganz kurz:

• externe Partitionen kann jeder einhängen, privilegiert oder nicht. Wenn der Administrator das nicht will, braucht er diese ja dem User nur nicht auszuhändigen.

• Aber interne Partitionen sind nun eben leider ’mal da. Deshalb braucht es einen Weg, den User daran zu hindern, wenn der Administrator das nicht will. Das ist das Hintsystem und ggf. die Passwort-Abfrage "Hey Administrator, darf der das wirklich?"

Und deshalb war ich eben der Ansicht, ohne Intervention des Administrators soll ein unprivilegierter Benutzer das gar nicht dürfen oder noch besser gar nicht können.

Aber in der Praxis ist das wohl gar nicht so wichtig. Denn so geschwind ’mal per GUI einbinden und dann wieder aushängen wird man wohl eh nur externe Partitionen (?), und da spielt das gar keine Rolle (hintsystem=no). Ich jedenfalls halte es so: Interne Partitionen nur per mount und mit Root-Rechten bzw. statisch per fstab. Deshalb hatte ich ja von dem ganzen hintsystem früher noch gar nichts gemerkt.

Max-Ulrich_Farber schrieb:

[…] Das von kB beschriebene Vorgehen in Post 9420544 sehe ich genau so. Es ist eben das ganz normale Vorgehen, und wenn es nicht die Geschichte mit dem rätselhaften nicht oder vielleicht auch doch verifizierbaren Bug gäbe, wäre alles klar. Nun meine Frage:

Wenn es unbedingt Weg 1 sein muss, dann (nur dann!!) muss auch auch die Anforderungen von FUSE beachten, d.h. SUID für ntfs-3g setzten und die Dateiberechtigungen für Einbindepunkt (problemlos) und Gerätedatei des Blockgerätes (sicherheitstechnisch höchst problematisch!!) erfüllen.

Muss denn unbedingt Weg 1 sein? Weil ich mir (bis jetzt) keinen Fall vorstellen kann, bei dem Weg 1 "unbedingt" sein muss (welches Anwendungsprogramm könnte dies z.B. verlangen?), habe ich vorgeschlagen, Weg 1 bei NTFS-3G einfach auszuschließen. Damit wären wir, meine ich, aus dem Schneider, für alle Arten von Anwendern. Doch vielleicht weiß jemand, wann und wofür man Weg 1 "unbedingt" braucht. Denn dann geht das natürlich nicht

Weg 1 können wir nicht ausschließen, sondern höchstens dringend davon abraten – was wir auch tun sollten.

Das ist normalerweise ein völlig legitimer Weg und sogar die langjährig eingebrannte Standardprozedur. Etliche Backup-Skripte setzen sie voraus und vermutlich andere Anwendungssoftware auch. Ich kann mir gut vorstellen, dass ein verzweifelter Administrator in die Verlegenheit kommen kann, diese sogar in Kenntnis besserer, aber in seinem konkreten Fall fehlschlagender Alternativen anzuwenden.

Selbst das UbuntuUsers-de-Wiki spricht fast überall von mount und nur in Ausnahmefällen von udisksctl. Erst in wenigen Tagen schalte ich die Grundlage frei, die das ändern kann. Bis sich das dann allgemein durchgesetzt hat, wird einige Zeit vergehen. Umso wichtiger ist, im Falle von ntfs-3g dringend von mount durch normale Benutzer (≠ root) abzuraten.

kB schrieb:

• Einzige Ausnahme ist ein für normale Benutzer einsetzbarer Eintrag in der fstab für mount, dieser benötigt users.

Nach meinem jüngsten Test ist für ntfs-3g users nicht "nötig", stört mount aber auch nicht. Einzig und allein zählt die Erfüllung der FUSE-Bedingungen, users wird nicht beachtet. Allerdings führt users zur Nichtfunktion von udisksctl mount.

UlfZibis schrieb:

kB schrieb:

• Einzige Ausnahme ist ein für normale Benutzer einsetzbarer Eintrag in der fstab für mount, dieser benötigt users.

Nach meinem jüngsten Test ist für ntfs-3g users nicht "nötig", stört mount aber auch nicht.

Bitte unterlasse es, aus meinen Beiträgen einzelne Sätze aus dem Zusammenhang zu reißen und in einen anderen, von mir nicht intendierten Kontext zu stellen. Ich sprach von mount, gestartet von einem normalen Benutzer, welches ntfs-3g startet. Dieses benötigt die Option user und ggf. weitere Voraussetzungen.

Einzig und allein zählt die Erfüllung der FUSE-Bedingungen, users wird nicht beachtet.

Natürlich beachtet mount die Option user. Wie schaffst Du es, mount als normaler Benutzer zu starten ohne diese Option?

Allerdings führt users zur Nichtfunktion von udisksctl mount.

Das beruht auf UDisks. Standardmäßig sind user & Co. keine für UDisks erlaubten Optionen. Das wiederum hat mit dem Programm mount gar nichts zu tun.

kB schrieb:

Ich sprach von mount, gestartet von einem normalen Benutzer, welches ntfs-3g startet.

Genau davon sprach ich auch. Wo ist das Missverständnis?

Wie schaffst Du es, mount als normaler Benutzer zu starten ohne diese Option?

Um weiteren Missverständnissen vorzubeugen, hier meine Befehlsfolge:

ich@T500:~$ cat /proc/version_signature
Ubuntu 5.15.0-100.110-generic 5.15.143
ich@T500:~$ lsb_release -d
Description:	Ubuntu 22.04.4 LTS
ich@T500:~$ mount /media/Sicherung
Error opening read-only '/dev/sda7': Keine Berechtigung
Failed to mount '/dev/sda7': Keine Berechtigung
Please check '/dev/sda7' and the ntfs-3g binary permissions,
and the mounting user ID. More explanation is provided at
https://github.com/tuxera/ntfs-3g/wiki/NTFS-3G-FAQ
ich@T500:~$ cat /etc/fstab | grep Sicherung
# /media/Sicherung was on /dev/sda7 during installation
UUID=2510AA16624BB80C   /media/Sicherung        ntfs    defaults,noauto,windows_names,hide_dot_files      0       0
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    defaults,noauto,users,windows_names,hide_dot_files      0       0
ich@T500:~$ mount /media/Sicherung
Error opening read-only '/dev/sda7': Keine Berechtigung
Failed to mount '/dev/sda7': Keine Berechtigung
Please check '/dev/sda7' and the ntfs-3g binary permissions,
and the mounting user ID. More explanation is provided at
https://github.com/tuxera/ntfs-3g/wiki/NTFS-3G-FAQ
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:~$ mount /media/Sicherung
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    defaults,noauto,windows_names,hide_dot_files      0       0
ich@T500:~$ mount /media/Sicherung
ich@T500:~$ umount /media/Sicherung
ich@T500:~$ 

Wie man beim letzten mount sehen kann, ist users nicht von Belang. Lediglich die "FUSE-Bedingungen" sind von Belang.

EDIT:

Allerdings führt users zur Nichtfunktion von udisksctl mount.

Das beruht auf UDisks. Standardmäßig sind user & Co. keine für UDisks erlaubten Optionen.

Wo ist das so definiert?
Ich würde eher sagen: UDisks sollte sich nicht um user & Co. kümmern, da nur für mount bestimmt. Das tut es allerdings. Wenn die "FUSE-Bedingungen" für 1000 erfüllt sind, führt users dazu, dass UDisks das Dateisystem mit Besitzer 1000 einbindet, statt mit 0, obwohl der Dienst udisksd unter root läuft. Siehe hier und hier.

Das wiederum hat mit dem Programm mount gar nichts zu tun.

Nichts anderes habe ich behauptet.

UlfZibis schrieb:

[…] Wie man beim letzten mount sehen kann, ist users nicht von Belang.

Nein, das kann man aus dem Protokoll nicht entnehmen, da das Ergebnis des Befehls mount /media/Sicherung nicht abgefragt wurde. Der Befehl kann erfolgreich gewesen sein oder gescheitert sein – wir wissen es nicht.

Wiederhole den Versuch unter Verwendung von mount -v statt mount und erfrage jeweils das Ergebnis mit echo $? !

kB schrieb:

Nein, das kann man aus dem Protokoll nicht entnehmen, da das Ergebnis des Befehls mount /media/Sicherung nicht abgefragt wurde. Der Befehl kann erfolgreich gewesen sein oder gescheitert sein – wir wissen es nicht.

Wenn er gescheitert wäre, hätte spätestens umount gemeckert. Außerdem hatte ich beim ersten Versuch gestern mittels ls -l /media/Sicherung überprüft, dass die Partition tatsächlich eingebunden wurde (So bin ich ja auch drauf gekommen, unter welchem Besitzer die Dateien eingebunden wurden.).

Das beruht auf UDisks. Standardmäßig sind user & Co. keine für UDisks erlaubten Optionen.

Trotzdem ist das komisch und für mich nicht erklärbar:

• bei NTFS-3G bindet udisks nicht ein, wenn in fstab die Option users steht. aber:

• bei exfat-fuse bindet aber udisks ein bei sonst gleichen Bedingngen, also mit users.

Das habe ich eben nochmal geprüft und bestätigt. Damit kann es also kein Feature von udisks und auch nicht von FUSE sein. Es muss an NTFS-3G liegen. Bug oder Feature, das kann ich nicht entscheiden. Ist hier aber auch gleichgültig. Ein warnender Hinweis ist so oder so angebracht.

Doch bei allem, was UlfZubis mit mount gemacht bzw. beobachtet hat, blicke ich nicht durch. Der Befehl mount ohne Root ging bei mir nicht, nicht ohne und auch nicht mit users und auch nicht mit sudo chmod +s /usr/bin/ntfs-3g. Ich habe in fstab aber ausdrücklich den Treiber ntfs-3g angegeben und nicht nur ntfs. Passiert ist nichts weiter, es ging halt nicht. Hat vielleicht UlfZibis ein Fallback provoziert?

Wegen des Verhaltens mit udisks genügt es halt leider nicht, einfach anzugeben "user und users werden von NTFS-3G nicht unterstützt".

Max-Ulrich_Farber schrieb:

Der Befehl mount ohne Root ging bei mir nicht, nicht ohne und auch nicht mit users und auch nicht mit sudo chmod +s /usr/bin/ntfs-3g.

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"?

Hat vielleicht UlfZibis ein Fallback provoziert?

Oh, das hätte ich tatsächlich noch überprüfen müssen. Allerdings sprach ein erfolgreiches touch /media/Sicherung/xxxxx für Erfolg (gestern schon getestet), denn der Fallback auf ntfs wäre ja read-only gewesen. Also nochmal genauer hingucken:

ich@T500:~$ cat /etc/fstab | grep Sicherung
# /media/Sicherung was on /dev/sda7 during installation
UUID=2510AA16624BB80C   /media/Sicherung        ntfs    defaults,noauto,windows_names,hide_dot_files      0       0
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:~$ 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:~$ ls -ld /media/Sicherung/Software
drwxrwxrwx 1 ich ich 4096 Jun 24  2022 /media/Sicherung/Software
ich@T500:~$ touch /media/Sicherung/xxxx
ich@T500:~$ rm /media/Sicherung/xxxx
ich@T500:~$ 

Wegen des Verhaltens mit udisks genügt es halt leider nicht, einfach anzugeben "user und users werden von NTFS-3G nicht unterstützt".

Das denke ich auch so.

UlfZibis schrieb:

kB schrieb:

Nein, das kann man aus dem Protokoll nicht entnehmen, da das Ergebnis des Befehls mount /media/Sicherung nicht abgefragt wurde. Der Befehl kann erfolgreich gewesen sein oder gescheitert sein – wir wissen es nicht.

Wenn er gescheitert wäre […]

Er ist bei Dir gescheitert und Du hast es nicht bemerkt, weil Du zu faul bist, es abzufragen. Statt dessen verbreitest Du hier FUD.

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
$ 

$ umount -v /media/Windows/
umount: /media/Windows (/dev/sda2) ausgehängt
$ umount -v /media/Windows/
umount: /media/Windows: nicht eingehängt.
$ 

Also mount beachtet users nicht? Quatsch, natürlich beachtet mount diese Option und verhält sich genau so wie beschrieben, eben regelgerecht!

kB schrieb:

Er ist bei Dir gescheitert und Du hast es nicht bemerkt, weil Du zu faul bist, es abzufragen.

Guck noch mal GENAU das Protokoll in meinem letzten Post.

Statt dessen verbreitest Du hier FUD.

HeHe !!!

Bei Dir funktioniert es vielleicht anders, weil Du die Option defaults (=rw,suid,dev,exec,auto,nouser,async,relatime) nicht verwendest.

Aber ohne defaults scheint users wohl einen Unterschied zu machen. Hilfe, es wird immer komplizierter.
(Da könnte es dann evtl. noch interessant sein, was udisksctl mount ohne defaults macht.)

Wenn es bei mir gescheitert wäre, hätte ich ja auch Deine Fehlermeldung bekommen müssen, und touch wäre gescheitert und umount hätte ebenfalls gemeckert.

Max-Ulrich_Farber schrieb:

• Aber interne Partitionen sind nun eben leider ’mal da. Deshalb braucht es einen Weg, den User daran zu hindern, wenn der Administrator das nicht will. Das ist das Hintsystem und ggf. die Passwort-Abfrage "Hey Administrator, darf der das wirklich?"

Ja, Max-Ulrich_Farber als Standard-Verhalten ist das so ja auch sinnvoll. Aber wenn ich doch als Administrator eine interne Partition Nutzern zum Einhängen zur Verfügung stellen will, weil ich ja besser als irgendeine Automatik entscheiden kann, was ich damit für Daten zugänglich mache, dann muss es ja einen Weg geben.

Und es ist ein völlig legitimer Weg, UDISKS_SYSTEM bzw. HintSystem mittels udev-Regel zu ändern, wenn ich das als Administrator gerne möchte.

Es ist ja nicht so, dass ein unprivilegierter Nutzer da am System herumschraubt, sondern dieser profitiert nur von der Zugänglichmachung durch den Administrator.

Insofern verstehe ich Deine Bedenken in diesem Punkt nicht.

LG, Newubunti

@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.

Aber ich habe folgendes gemacht: Alle Versuche möglichst genau gleich mit dem anderen FUSE-Treiber exfat-fuse parallel durchgeführt:

• bei exfat-fuse gab es keinerlei Überraschungen. Alles lief genau so ab, wie erwartet zw. wie es sollte, FUSE-Bedingungen hin oder her. Sowohl bei mount mit oder ohne users als auch bei udiskctl mount -b bzw. gio mount -d. Alles IMO völlig "normal".

• bei ntfs-3G habe ich nicht so viele Parameter verändert wie UlfZibis. Ich mache das immer einzeln, ein Parameter nach dem andern, und da wäre ich bis jetzt noch nicht mit allen fertig. Aber auch so habe ich genügend seltsames und mir unverständliches Verhalten beobachtet:

  • udisksctl mount -u reagiert auf users indem es nicht mehr einbindet, aber

  • sudo udisksctl mount -u (das tut man ja eigentlich nicht…) bindet ein, wenn users gesetzt ist

  • bei mount genau gleich, dürfte aber eigentlich nicht so sein

  • umount klapptt hingegen ohne Root-Rechte, wenn users gesetzt ist (normales Verhalten)

  • SUID-Bit für /usr/bin/ntfs-3g ändert gar nichts.

Ob das Ein- und Aushängen wirklich stattfand, habe ich immer parallel auch in der GUI beobachtet.

Ich kann mir wirklich keinen Reim auf alles dies machen. Aber der Bug (so sehe ich es inzwischen auch) steckt wohl ziemlich tief drin, sodass er sich an einer Stelle auswirkt, die bei mount und udisksctl ausgeführt wird. Die anderen skurrilen Ergebnisse von UlfZibis könnten vielleicht daher kommen, dass beim Schrauben an den vielen Parametern möglicherweise "weiter außen" noch Auswirkungen auftraten, z.B. in FUSE oder beim "Filter" für Optionen in udisks2 oder wer weiß wo. Vielleicht ist aber auch alles ganz anders. Ich muss passen, ich verstehe das nicht.

Zum Glück muss ich keinen Fehlerbericht schreiben, sondern "nur" einen Wiki-Artikel. Und da ist die Sache IMO ziemlich klar: Finger weg von user(s) bei NTFS-3G!. Basta.

@ Newubunti:

Insofern verstehe ich Deine Bedenken in diesem Punkt nicht.

Ach, ich gebe dir ja Recht. Da kommt bei mir nach so vielen Jahren halt wieder ’mal der frühere Lehrer zum Vorschein: Immer den Schülern auf die Finger schauen, dass sie ja nichts tun, was sie nicht dürfen, kein Spickzettel unter der Bank oder, noch schlimmer, bei den Mädchen im Ausschnitt. Wer nicht aufpasst, wird ausgetrickst. "Déformation professionelle" nennt man das in Frankreich…

Es ist wahr, der Administrator sitzt immer noch am längeren Hebel, denn natürlich kann nur er die udev-Regel ändern, und Unprivilegierte können sich keine Privilegien erschwindeln. 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.

L.G. Max-Ulrich

Max-Ulrich_Farber schrieb:

Alle Versuche möglichst genau gleich mit dem anderen FUSE-Treiber exfat-fuse parallel durchgeführt:

• bei exfat-fuse gab es keinerlei Überraschungen. Alles lief genau so ab, wie erwartet zw. wie es sollte, FUSE-Bedingungen hin oder her.

Wenn es bei exfat-fuse nicht auf die von kB so genannten 3 "FUSE-Bedingungen" ankommt, dann wäre deren Namens-Definition evtl. noch mal zu überdenken, also sie vielleicht besser "NTFS-3G-Bedingungen" nennen.

Sowohl bei mount mit oder ohne users

Das klingt so, als würde users dafür sorgen, dass die "NTFS-3G-Bedingungen" erfüllt werden. Genau so würde ich das auch gemäß mount erwarten, und wenn nicht, sehe ich das als Bug.

als auch bei udiskctl mount -b bzw. gio mount -d. Alles IMO völlig "normal".

Macht dabei users einen Unterschied?

• bei ntfs-3G habe ich nicht so viele Parameter verändert wie UlfZibis. Ich mache das immer einzeln, ein Parameter nach dem andern,

Ich hatte bei meinem ersten Test auch immer nur einen Parameter geändert. Da es aber egal war, welche der 3 "NTFS-3G-Bedingungen" ich deaktiviert hatte, hatte ich das im Bericht dann zusammengefasst.

• SUID-Bit für /usr/bin/ntfs-3g ändert gar nichts.

Ändert nur was, wenn die beiden anderen "NTFS-3G-Bedingungen" erfüllt sind – nehme ich mal an – jedenfalls war es bei mir so.

Und da ist die Sache IMO ziemlich klar: Finger weg von user(s) bei NTFS-3G!. Basta.

... dabei aber vlt. auch anmerken, dass mount sich bei erfüllten "NTFS-3G-Bedingungen" und der Option defaults so verhält, als wäre user(s) gesetzt.