ubuntuusers.de

Danke, Newubunti.

Die Begründungen für deine Entscheidungen leuchten mir ein. Auch das Weglassen der udev-Regel. Aber auf den Hinweis, dass man ab Ubuntu 23.10 bzw. udisks 23.10 auch für udisks2 bzw. gio mount den Treiber über /etc/udisks2/mount_options.conf wählen kann sollten wir nicht verzichten. Wenn du das jetzt so vollends fertig machst, bin ich froh, dass ich es nicht mehr tun muss 😀 👍

Im Artikel gio mount habe ich jetzt gio mount (Abschnitt „Einbinden-lokaler-Dateisysteme“) inhaltlich aktualisiert, sodass darauf verwiesen bzw. verlinkt werden kann. Die Gliederung gefällt mir noch nicht ganz, die dürfte etwas feingliedriger sein. Aber darum kümmere ich mich später nochmal. Bei den übrigen Abschnitten des Artikels sehe ich im Moment nichts, was so nicht mehr gilt – außer vielleicht die restriktive Aussage zu NTFS (?).

Dann könnte wohl der Artikel NTFS-3G zurückgeschoben werden. Und für den Artikel NTFS3 ist auch schon ganz schön viel Material beisammen! Vielleicht könnte jemand 'mal alles Relevante zusammenfassen und in die Diskussion von NTFS3 übernehmen, sodass man dann dort weiterarbeiten könnte.

Grüße und vielen Dank, Max-Ulrich Farber

EDIT:

Halt, bitte noch nicht zurückschieben! Bei User Mapping besteht noch Handlungsbedarf. Darum wollte ja ich mich noch kümmern.

Max-Ulrich_Farber schrieb:

Danke, Newubunti.

Die Begründungen für deine Entscheidungen leuchten mir ein. Auch das Weglassen der udev-Regel. Aber auf den Hinweis, dass man ab Ubuntu 23.10 bzw. udisks 23.10 auch für udisks2 bzw. gio mount den Treiber über /etc/udisks2/mount_options.conf wählen kann sollten wir nicht verzichten. Wenn du das jetzt so vollends fertig machst, bin ich froh, dass ich es nicht mehr tun muss 😀 👍

Ja, da sitze ich gerade noch dran und bin am überlegen, wie ich das möglichst kurz und knackig einbringe.

Ich bitte darum, mit dem Verschieben noch ein bisschen zu warten!

Mir ist auch noch aufgefallen, dass wir in Deiner überarbeiteten Einleitung und meiner Einleitung des Abschnittes "Einhängen.." IMO vermeidbare Redundanz bezüglich ntfs3 habe. Ich wäre dafür, dass wir das mit ntfs3 beim Einhängen kurz abarbeiten. In der Einleitung nur beschreiben, was ntfs-3g ist. Dann ist diese auch gleich um einen Absatz kürzer.

LG, Newubunti

Newubunti schrieb:

[…] Ich bitte darum, mit dem Verschieben noch ein bisschen zu warten!

Generell wird ins Wiki verschoben erst nach Fertigmeldung des Bearbeiters plus 2 Wochen Bedenk- und Diskussionszeit für die UU-Gemeinschaft.

Mir ist auch noch aufgefallen, dass wir in Deiner überarbeiteten Einleitung und meiner Einleitung des Abschnittes "Einhängen.." IMO vermeidbare Redundanz bezüglich ntfs3 habe. Ich wäre dafür, dass wir das mit ntfs3 beim Einhängen kurz abarbeiten. In der Einleitung nur beschreiben, was ntfs-3g ist. Dann ist diese auch gleich um einen Absatz kürzer.

Es besteht ja schon eine Baustelle für ntfs3. Da kann man gerne unten aus ntfs-3g Ausgelagertes bunkern, quasi als Stoffsammlung.

kB schrieb:

Es besteht ja schon eine Baustelle für ntfs3. Da kann man gerne unten aus ntfs-3g Ausgelagertes bunkern, quasi als Stoffsammlung.

Danke, für den Hinweis kB! Sobald ich hier soweit fertig bin, mache ich bzw. versuche ich 😬 eine Zusammenfassung der hier gesammelten, für ntfs3 relevanten Erkenntnisse.

LG, Newubunti

@Newubunti (off topic, aber vielleicht für alle interessant):

Das Kernel-Upgrade von 5.15.0-100 auf 6.5.0-25 hat auch in XUbuntu (mit XFce) problemlos geklappt, und alles scheint zu funktionieren. Ich meine, auf meiner betagten Hardware einen fühlbaren Gewinn an Performance zu erkennen (objektiv gemessen habe ich nichts).

Danke, für die Rückmeldung @Max-Ulrich_Farber!

Ich bin jetzt mit der Bearbeitung des Abschnitts "Einhängen..." aus meiner Sicht grundsätzlich fertig. Ich denke das müsste so klar nachvollziehbar für den Leser sein, allerdings missfällt mir selbst die Länge des Abschnittes noch. Aber ich denke, da wird man vorläufig mit leben müssen, solange es keinen Artikel gibt, der das grafische Einhängen auf Grundlage von udisks bzw. einfach nur zu udisks gibt.

Eine diesbezügliche Auslagerung nach gio bzw. gio mount halte ich für nicht so günstig, da gio nicht überall verfüg- bzw. nutzbar (KDE Plasma). Es wird also vom Leser dort im Zweifel nicht gesucht bzw. erwartet.

Noch offen wäre jetzt der Punkt mit windows_names-Standard.

Ich wollte gerade mal im mehr oder weniger jugendlichen Leichtsinn mir einen schnellen Überblick über die Standards beim Einbinden mittels Klick verschaffen und habe da gerade wieder eine Begegnung mit meinem "Endgegner" bei diesem Thema, dem FUSE-NTFS-3G-internes-FUSE-Dschungel. Für die Option windows_names selbst gar nicht so sehr bedrohlich, aber ich dachte, ich könnte bei der Gelegenheit allow_oterhs verstehen. Heute allerdings wohl nicht mehr. 😀

LG, Newubunti

Die manpages-Links kann man auch kürzer (ohne tracking) schreiben, z.B.: https://manpages.ubuntu.com/cgi-bin/search.py?q=udisks

Oder man nimmt gleich die Vorlage: udisks

Bei mir werden Dateien auf externen NTFS-Laufwerken MIT Ausführungsrechten unter $USER eingebunden.

EDIT: Außerdem denke ich, dass man den Abschnitt Baustelle/Windows-Partitionen einbinden/NTFS-3G (Abschnitt „Dual-Boot-und-Ruhezustand-Hibernate“) in den übergeordneten Artikel schieben könnte, denn das gilt ja auch für NTFS3.
Auch manch anderes unter Probleme und Lösungen gilt eher allgemein.

So wird der Artikel auch noch etwas schlanker.

Außerdem denke ich, dass man den Abschnitt Baustelle/Windows-Partitionen einbinden/NTFS-3G (Abschnitt „Dual-Boot-und-Ruhezustand-Hibernate“) in den übergeordneten Artikel schieben könnte, denn das gilt ja auch für NTFS3.

Ja, denn das gilt ganz allgemein für Dual-Boot Systeme, auch VFAT, exFAT usw. Der Treiber NTFS-3G hat da sogar noch eine Notbremse eingebaut: System-Partitionen in Windows-Ruhe werden nur ro eingebunden. Wie das bei NTFS3 ist, weiß ich nicht. Das sind eben die wichtigen "Kleinigkeiten", für die es in NTFS3 an Dokumentation arg fehlt!

Ich denke, so lange bis der übergeordnete Artikel fertig ist, müssen solche dringenden Warnungen aber in dem Artikel bleiben. Umsetzen kann man sie dann später immer noch.

UlfZibis schrieb:

Oder man nimmt gleich die Vorlage: udisks

Danke, für den Hinweis! Habe ich gerade berichtigt.

Deinen Link auf den BUG-Report (Stichwort: noauto,user(s)), weil unklar, ob das überhaupt ein BUG oder Ursache des restriktiven Mount-Verhaltens von ntfs-3g ist. Dazu antworte ich Dir heute auch noch in Deinem diesbezüglichen Thread.

LG, Newubunti

Newubunti schrieb:

Deinen Link auf den BUG-Report (Stichwort: noauto,user(s)), weil unklar, ob das überhaupt ein BUG oder Ursache des restriktiven Mount-Verhaltens von ntfs-3g ist. Dazu antworte ich Dir heute auch noch in Deinem diesbezüglichen Thread.

Eben weil die Sache unklar ist, finde ich einen Hinweis auf die Stelle, die diese Unklarheit behandelt, und (hoffentlich) in Zukunft ausmerzt wird, sinnvoll. Die Unklarheit ist erst aufgehoben, wenn entweder dem "restriktiven Mount-Verhalten von ntfs-3g" abgeholfen wird, oder dieses in mount dokumentiert ist. Man könnte auch sagen, ntfs-3g hält sich nicht an den "contract" von mount, ist also "nicht kompatibel", wobei es auch sein kann, dass die "Inkompatibilität" durch die Zwischenschichten FUSE oder udisks "verschuldet" wird. Für letzteres spricht der Kommentar der Entwickler.
Die Aussage

Seit Ubuntu 22.04 muss beim vorbereitenden, statischen Einhängen auf die allgemeinen Mount-Optionen user und users verzichtet werden, weil das Einbinden andernfalls scheitert.

, welche aktuell für >= 22.04 noch richtig ist, könnte in Zukunft wieder eine falsche sein.

EDIT: Hat eigentlich jemand schon mal getestet, wie sich NTFS3 unter den Optionen noauto,user(s) verhält ?

Newubunti schrieb:

[…] Aber ich denke, da wird man vorläufig mit leben müssen, solange es keinen Artikel gibt, der das grafische Einhängen auf Grundlage von udisks bzw. einfach nur zu udisks gibt.

Gibt es, jedenfalls als Baustelle.

UlfZibis schrieb:

, welche aktuell für >= 22.04 noch richtig ist, könnte in Zukunft wieder eine falsche sein.

Das kann für diesen Artikel nur dann in größerer Bedeutung falsch werden, wenn die Entwickler von ntfs-3g ermöglichen, dass Ihr Treiber im Zusammenspiel mit FUSE und gesetztem SUID-Bit für mount.ntfs-3g das Einhängen erlaubt, ohne dass der Nutzer, der mount.ntfs-3g initiiert, auch noch zusätzlich lesend und schreibend auf /dev/... zugreifen können muss.

Da sie davon aber schon seit mindesten 12 Jahren kein Abstand nehmen, glaube ich nicht daran, dass sich das zeitnah ändern wird, zumal man das in der Praxis heute eigentlich auch nicht mehr in der Form braucht.

Aber das bitte - falls gewünscht - in Deinem Thread diskutieren. Da habe ich auch noch ein wenig ausführlicher Stellung zu bezogen.

LG, Newubunti

Newubunti schrieb:

[…] wenn die Entwickler von ntfs-3g ermöglichen, dass Ihr Treiber im Zusammenspiel mit FUSE und gesetztem SUID-Bit für mount.ntfs-3g das Einhängen erlaubt, ohne dass der Nutzer, der mount.ntfs-3g initiiert, auch noch zusätzlich lesend und schreibend auf /dev/... zugreifen können muss.

Die Entwickler von ntfs-3g haben damit nichts zu tun. Die genannten technischen Eigenschaften gehören zu den von FUSE bestimmten Voraussetzungen für die Einbindung eines Dateisystems über den (bei Ubuntu fest eingebauten) Kernel-Modul fuse. Es ist weder zu erwarten noch überhaupt wünschenswert, dass die Kernel-Entwickler daran etwas ändern, weil sonst ein Sicherheitsloch aufgerissen würde.

Hier blicke ich (wieder einmal) nicht ganz durch. Das Verhalten im Zusammenhang mit NTFS-3G leuchtet mir ein, und ich sehe auch nicht, warum man heute noch die Optionen users und user mit SUID-Bit überhaupt noch braucht. In Desktop-Systemen sind sie unnötig, und wer wird einen Server so einrichten, dass er dort solche Sicherheits-Risiken einbaut?

Doch offenbar klappen users und user bei anderen FUSE-Treibern, z.B. exFAT. Oder klappen sie nicht wirklich und werden nur einfach ignoriert? Ich habe das nicht ausprobiert.

EDIT:

In Desktop-Systemen sind sie unnötig, und wer wird einen Server so einrichten, dass er dort solche Sicherheits-Risiken einbaut?

Ich habe nochmal ein bisschen nachgedacht. "In Desktop-Systemen sind sie unnötig" stimmt nur für lokale Dateisysteme. Beim Einbinden von Netzwerk- Dateisystemen können ja gio mount und damit auch GUI und DM nicht auf den fstab-Eintrag zurückgreifen, und beide Zugriffsarten bestehen völlig unabhängig voneinander. Man muss also mit solchen Verallgemeinerungen vorsichtig sein. ☺

Max-Ulrich_Farber schrieb:

[…] warum man heute noch die Optionen users und user mit SUID-Bit überhaupt noch braucht.

Die Einbindung eine Dateisystems ist generell eine die Sicherheit des Systems gefährdende Operation, weil dadurch Schadsoftware ins System gelangen und ausgeführt werden kann. Beispielsweise kann man durch ein passend präpariertes Dateisystem bei dessen Einbindung die Rechte eines Systemverwalters erlangen. Aus diesem Grund ist die Operation solchen Benutzern vorbehalten, welche bereits Systemverwalter sind oder ein Programm wie mount oder ntfs-3g oder einen Dienst wie UDisks benutzen dürfen, welches selbst schon die Rechte eines Systemverwalters besitzt. Diese Gehülfen müssen dann natürlich kontrollieren, welche normalen Benutzer sie zulassen.

Die Optionen user und users sind selbst gar keine Optionen für den jeweiligen Dateisystemtreiber, sondern dienen nur der Verwaltung des Ein- und Ausbindevorgangs. Sie gehen also eigentlich nur mount etwas an und höchstens informativ mount.ntfs-3g alias ntfs-3g. Das Programm ntfs-3g behandelt diese aber Optionen falsch, wie ich bereits früher schon mal bemerkt habe:

• Wenn man keine Option verwendet, die ein Wortteil user enthält, so verhält sich ntfs-3g so, als ob man nouser (=Vorgabe) verwendet hätte. Das ist noch richtig.

• Wenn man aber eine solche Option verwendet, z.B. nouser oder user oder luser_schiss_dich_tot, dann interpretiert das ntfs-3g als users. Das ist ein BUG.

Man darf also bei ntfs-3g nur die Option users oder gar nichts aus dieser Familie angeben, und muss nouser, user und alle anderen Optionen, welche user enthalten, vermeiden.