pit234a
Well-Known Member
ich stolpere gerade wieder über die Thematik NTFS, weil ich es inzwischen als DAS Austausch-Dateisystem für meine größeren USB-Sticks benutze und endlich auch mal in FreeBSD dann Dateisysteme erzeugen möchte. Aus meinem Bauchgefühl heraus habe ich das bisher nie gemacht und alles immer von einem Windows formatiert, was ich mit NTFS haben wollte. Seit einigen Jahren habe ich keine Probleme mehr mit ntfs-3g auf unterschiedlichen Plattformen erlebt. Deshalb wagte ich nun diesen Schritt und bin noch am probieren.
Was ich schon mal direkt sagen möchte: nachdem ich mit einem
chmod +s /usr/local/bin/ntfs-3g
mal testen wollte, ob danach mein User mounten kann, erhielt ich diese Meldung:
Das sagt mir, dass grundsätzlich eine Möglichkeit bestehen könnte, dass dazu aber Eigenbau aus den Ports notwendig ist. Ich möchte das nicht. Daher lebe ich lieber damit, nicht als User zu mounten.
Inwiefern hat das etwas mit diesem Thema zu tun?
Ich will das teilen, denn automatischer Mount ist nicht ausreichend definiert und führte auch hier schon zu unterschiedlichen Interpretationen.
-1) automatisches Einbinden über einen Eintrag in der fstab (beim Booten)
-2) automatisches Mounten durch ein script oder einen Dienst zur Laufzeit
-1) der Eintrag in einer fstab führt dazu, dass ein "Root-Mount" beim Booten durchgeführt wird. Solche Einträge können sich nur auf ständig vorhandene Speichermedien beziehen. Diese müssen zur Bootzeit vorhanden sein, ansonsten kann das System hängen bleiben oder wenigstens den Start lange verzögern.
Die Option "noauto" kann ein automatisches Einbinden zur Bootzeit verhindern. Der Eintrag in der fstab stellt dann eine Abkürzung für einen manuellen Mount dar, den Root später ausführen kann.
-2) es gibt viele Möglichkeiten, weshalb hier genauer auf den Einzelfall geschaut werden müsste. Generell kann man vielleicht sagen, dass ein Programm oder Dienst die Mount-Funktion automatisch aufrufen muss und dass solch ein Dienst maximal aus User begriffen werden kann. Das bedeutet, solange das unveränderte ntfs-3g aus den Paketen benutzt wird, dürfe kein Weg möglich sein, dass irgendein Dienst diesen Mount erfolgreich initiieren könnte. Um Nachforschungen anzustellen, müsste man sich ansehen, ob der entsprechende Dienst ein Gerät richtig erkennt und dann einen Mount-Aufruf generiert, der überhaupt passt. Ist dies der Fall, könnte man vielleicht darüber nachdenken, diesen Dienst mit höheren Rechten auszustatten, ihn quasi als Root laufen zu lassen. Ich würde das nicht machen, aber es wäre vielleicht eine Möglichkeit.
Die Analyse ist nicht sehr kompliziert, aber sehr zeitintensiv, besonders dann, wenn HAL benutzt wird. Es gibt aber Monitorringfunktionen, um dem Geschehen auf den grund zu gehen. lshal ist nur der Anfang, um zu sehen, was da erkannt wird. Ich will das aber hier nicht weiter führen.
Es erscheint mir eben nach Verlauf dieses Threads sehr wichtig, dass wir genauer hinsehen, worüber wir eigentlich reden wollen. Automount ist offenbar nicht eindeutig genug.
Außerdem wiederhole ich nochmal den Rat, in die ausgezeichneten Wiki's bei Ubuntu oder Arch zu sehen, etwa:
https://wiki.archlinux.org/index.php/NTFS-3G
Was ich schon mal direkt sagen möchte: nachdem ich mit einem
chmod +s /usr/local/bin/ntfs-3g
mal testen wollte, ob danach mein User mounten kann, erhielt ich diese Meldung:
Code:
pit@senyo ~:- > ntfs-3g -o rw /dev/da1s1 /mnt/usb1
Mount is denied because setuid and setgid root ntfs-3g is insecure with the
external FUSE library. Either remove the setuid/setgid bit from the binary
or rebuild NTFS-3G with integrated FUSE support and make it setuid root.
Please see more information at
http://tuxera.com/community/ntfs-3g-faq/#unprivileged
Inwiefern hat das etwas mit diesem Thema zu tun?
Ich will das teilen, denn automatischer Mount ist nicht ausreichend definiert und führte auch hier schon zu unterschiedlichen Interpretationen.
-1) automatisches Einbinden über einen Eintrag in der fstab (beim Booten)
-2) automatisches Mounten durch ein script oder einen Dienst zur Laufzeit
-1) der Eintrag in einer fstab führt dazu, dass ein "Root-Mount" beim Booten durchgeführt wird. Solche Einträge können sich nur auf ständig vorhandene Speichermedien beziehen. Diese müssen zur Bootzeit vorhanden sein, ansonsten kann das System hängen bleiben oder wenigstens den Start lange verzögern.
Die Option "noauto" kann ein automatisches Einbinden zur Bootzeit verhindern. Der Eintrag in der fstab stellt dann eine Abkürzung für einen manuellen Mount dar, den Root später ausführen kann.
-2) es gibt viele Möglichkeiten, weshalb hier genauer auf den Einzelfall geschaut werden müsste. Generell kann man vielleicht sagen, dass ein Programm oder Dienst die Mount-Funktion automatisch aufrufen muss und dass solch ein Dienst maximal aus User begriffen werden kann. Das bedeutet, solange das unveränderte ntfs-3g aus den Paketen benutzt wird, dürfe kein Weg möglich sein, dass irgendein Dienst diesen Mount erfolgreich initiieren könnte. Um Nachforschungen anzustellen, müsste man sich ansehen, ob der entsprechende Dienst ein Gerät richtig erkennt und dann einen Mount-Aufruf generiert, der überhaupt passt. Ist dies der Fall, könnte man vielleicht darüber nachdenken, diesen Dienst mit höheren Rechten auszustatten, ihn quasi als Root laufen zu lassen. Ich würde das nicht machen, aber es wäre vielleicht eine Möglichkeit.
Die Analyse ist nicht sehr kompliziert, aber sehr zeitintensiv, besonders dann, wenn HAL benutzt wird. Es gibt aber Monitorringfunktionen, um dem Geschehen auf den grund zu gehen. lshal ist nur der Anfang, um zu sehen, was da erkannt wird. Ich will das aber hier nicht weiter führen.
Es erscheint mir eben nach Verlauf dieses Threads sehr wichtig, dass wir genauer hinsehen, worüber wir eigentlich reden wollen. Automount ist offenbar nicht eindeutig genug.
Außerdem wiederhole ich nochmal den Rat, in die ausgezeichneten Wiki's bei Ubuntu oder Arch zu sehen, etwa:
https://wiki.archlinux.org/index.php/NTFS-3G