staging.inyokaproject.org

Hallo,

ich habe etwas mount und /etc/fstab herumexperimentiert und dabei sind mir noch ein paar Dinge nicht klar. Ich hoffe, ihr könnt mir hier weiterhelfen ☺.

Folgender Eintrag in der /etc/fstab:

/dev/sdb1  /mnt/data     ext4     defaults,noauto                                          0  2

1) Der mount Ordner /mnt/data gehört root:root. Warum gehört nach sudo mount /mnt/data der Ordner /mnt/data nun dem aktuellen user (<user>:<user>)?

(Falls relevant: /dev/sdb1 wurde früher mit Dolphin ohne sudo schon mehrfach nach /media/<user>/data gemountet.)

2) Warum muss ich erst mounten und dann die Berechtigungen des mount Ordners anpassen? Warum sind Berechtigungen des Ordners vor dem Mounten anders als nach dem Mounten? (Das Ziel war, dass der mount Ordner 700 Bereichtungen haben sollte. Bei "erst mount, dann chmod" ist die Partition für kurze Zeit für alle lesbar mit 755 gemountet.)

$ sudo mkdir /mnt/data
$ sudo chmod 700 /mnt/data
$ ls -l /mnt
drwx------  2 root root 4096 Apr  9 16:32 data
$ sudo mount /mnt/data
$ ls -l /mnt
drwxr-xr-x  3 <user> <user> 4096 Apr  9 16:33 data
$ sudo chmod 711 /mnt/data  # 711 gewählt, um von vorherigem 700 unterscheiden zu können

Die Änderung ist nun persistent gespeichert und nach dem Mounten sind die Berechtigungen immer 711, auch wenn man den mount Ordner ändert nach z.B. /mnt/data_2. Das gleiche gilt, falls man den Eintrag aus der /etc/fstab wieder entfernt und dann via Dolphin und (vermutlich) udisks2 nach /media/<user>/data mountet. Nach dem Unmounten sind die Berechtigungen wieder bei 700.

Wo wird diese Information (welche Berechtigungen der mount Ordner nach dem Mounten haben soll) gespeichert?

3) Obwohl für die Einträge in der /etc/fstab implizit durch defaults die nouser Option gesetzt ist, kann mittels Dolphin ohne sudo die Partition eingebunden werden (ein mount in der Konsole ohne sudo funktioniert hingegen nicht).

Verstehe ich es richtig, dass dies daran liegt, weil der verwendete user in der Gruppe plugdev ist?

Damit würde ein Eintrag nouser in der /etc/fstab nicht ausreichen, um einen weiteren User, der ebenfalls in der Gruppe plugdev ist, davon abzuhalten, die eigentlich "verbotene" Partition zu mounten und es benötigt noch Anpassungen an den Berechtigungen des mount Ordners. Sehe ich das richtig so?

Viele Grüße

Hallo, Mr. Threepwood!

guy.brush schrieb:

1) Der mount Ordner /mnt/data gehört root:root. Warum gehört nach sudo mount /mnt/data der Ordner /mnt/data nun dem aktuellen user (<user>:<user>)?

Tut er nicht, bzw nicht immer. Du mountest ja eine Partition mit einem Dateisystem. Die Rechte dieses Dateisystems entsprechen den Rechten des gemounteten. Als Nicht-Nachmachen-Beispiel: Du änderst mittels sudo chown -R 1001:1002 / das komplette Wurzelverzeichnis und schrottest das System damit. Hängst du diese Partition dann zum Datenretten nach /mnt/retten des LiveUsb, dann gehört „retten“ 1001 und 1002. Unabhängig von Benutzernamen, etc, auch wenn es die Nutzer gar nicht gibt.
Warum der Ordner also dem aktuellen User gehört: Er wurde vorher mal dem User übereignet. Manuell durch chown, eine GUI, wasauchimmer.

2) Warum muss ich erst mounten und dann die Berechtigungen des mount Ordners anpassen? Warum sind Berechtigungen des Ordners vor dem Mounten anders als nach dem Mounten? (Das Ziel war, dass der mount Ordner 700 Bereichtungen haben sollte. Bei "erst mount, dann chmod" ist die Partition für kurze Zeit für alle lesbar mit 755 gemountet.)

Sollte mit 1 klar sein, aber: Vor dem mounten ist das ein normaler, leerer Ordner. Als Einhängepunkt benutzt, bekommt er automatisch die Berechtigung, die auch das Wurzelverzeichnis der gemounteten Datenpartition hat. Für neu angelegte Dateien gibt es eine umask.

3) Obwohl für die Einträge in der /etc/fstab implizit durch defaults die nouser Option gesetzt ist, kann mittels Dolphin ohne sudo die Partition eingebunden werden (ein mount in der Konsole ohne sudo funktioniert hingegen nicht).

Dolphin, bzw. KIO mountet nicht wirklich. KIO bietet eine Schnittstelle, die unabhängig von der verwendeten Datentransporte (ssh, http, ftp, Festplatten, CDs, Alienfunksignale,…) die Daten verwenden kann und das auf Userbasis. Zum Verständnis ist da gvfs-mount einfacher. Das mountet nach /var/run/user/$(id -u) und braucht zum mounten ebenfalls root-Rechte. Diese bekommt es aber quasi bei der Installation schon mit. Du als Nutzer merkst davon nichts, weil es klammheimlich im Hintergrund abläuft.

Verstehe ich es richtig, dass dies daran liegt, weil der verwendete user in der Gruppe plugdev ist?

Plugdev is meine ich ausschliesslich USB, wobei ich mir dann gerade nicht sicher bin, wieso ich dialout brauche… Muss ich noch mal nachgucken.

Damit würde ein Eintrag nouser in der /etc/fstab nicht ausreichen, um einen weiteren User, der ebenfalls in der Gruppe plugdev ist, davon abzuhalten, die eigentlich "verbotene" Partition zu mounten und es benötigt noch Anpassungen an den Berechtigungen des mount Ordners. Sehe ich das richtig so?

Wer root-Rechte hat, darf alles. Wer in der entsprechenden Gruppe ist, darf da alles. Also ja, du könntest nicht zwei Nutzern nur durch die Gruppenzugehörigkeit unterschiedliche Rechte im Bereich dieser Gruppe geben. Es gibt natürlich immer Wege das zu manipulieren, bspw. bei einem USB-Gerät mit UDEV. Aber ist an sich nicht Sinn und Zweck einer Gruppe. Da geht es ja darum den Nutzern diese Rechte zu geben, sonst wären sie nicht drin. Noch feingranularer wären ACL.

Erstmal vielen Dank für deine Hilfe bisher ☺.

ChickenLipsRfun2eat:

Tut er nicht, bzw nicht immer. Du mountest ja eine Partition mit einem Dateisystem. Die Rechte dieses Dateisystems entsprechen den Rechten des gemounteten. [...]

Ah, ich glaube, ich habe meinen Denkfehler gefunden: Ich denke bei Ordnern wie in Boxen. Öffne ich eine Box, sehe ich, was sich in der Box befindet, weiß aber nicht mehr die Details, die die äußere Box betroffen; in diesem Fall die Berechtigungen und owner und group der äußeren Box. Daher auch die Frage ursprünglich: Woher weiß ich denn in der Box (im Ordner), was die Berechtigungen der äußeren Box sind? Das sind doch die Berechtigungen des mount Ordners! Und zwar so, wie ich sie vor dem Mounten festgelegt habe! Also, das war das, wie ich mir das zuvor vorgestellt hatte.

Allerdings gibt es in der Box ja den berühmten Ordner (bzw. eine weitere Box) mit dem Namen ./ Daher weiß ich auch in der Box, welche Berechtigungen, owner und group die äußere Box hat und diese Informationen werden auch "in der Box" gespeichert und nicht außerhalb. Anders ausgedrückt, wenn alle Ordner und Dateien in /mnt/data 1000:1000 gehören, der Ordner /mnt/data selbst aber 1005:1005 mit 700, ich diese Platte ausbaue und an einem anderen Linux-PC einbaue und dort mounte, dann gehört auch dort der mount Ordner 1005:1005 mit 700 (und der Inhalt, wie du schon mit deinem Nicht-Nachmachen-Beispiel sagtest, 1000:1000).

Ist das richtig so?

Ich bin eben immer davon ausgegangen, dass diese Informationen (Berechtigungen, owner, group) des äußeren Ordners auch außerhalb gespeichert werden.

Dazu kommt, dass ich wohl in der Vergangenheit /mnt/data einmal selbst mit chown verändert habe und mich nur nicht mehr daran erinnern konnte.

Sollte mit 1 klar sein, aber: Vor dem mounten ist das ein normaler, leerer Ordner. Als Einhängepunkt benutzt, bekommt er automatisch die Berechtigung, die auch das Wurzelverzeichnis der gemounteten Datenpartition hat. Für neu angelegte Dateien gibt es eine umask.

Ja, ich glaube, dass das jetzt klarer ist. Danke!

Plugdev is meine ich ausschliesslich USB, wobei ich mir dann gerade nicht sicher bin, wieso ich dialout brauche… Muss ich noch mal nachgucken.

Ich habe alle möglichen Gruppen meines Hauptusers durchprobiert bei einem Testuser: plugdev wird definitiv nicht benötigt, aber dafür sudo! Sobald der Testuser in der Gruppe sudo ist, kann er via Dolphin interne Festplatten (alle SATA angeschlossen; externe USB-Festplatten nicht getestet) einhängen und das ohne Passwort. Ist er nicht in der sudo Gruppe, kommt ein Fenster, bei dem man ein Passwort eingeben darf. Gibt man hier das Passwort des Hauptusers (der ja in sudo ist) ein, wird erfolgreich gemountet, obwohl man eben als Testuser eingeloggt ist. Hier werden also ein paar Schritte auf einmal gemacht.

Im Wiki Benutzer und Gruppen (Abschnitt „Gruppen“) wird dialout für 16.04 und 18.04 mit einem roten Kreuz versehen. Vielleicht heißt das, dass man seit den Versionen die Gruppe nicht mehr benötigt für die gewünschten Aktionen?

Wer root-Rechte hat, darf alles. Wer in der entsprechenden Gruppe ist, darf da alles. [...]

Hmm, also ich möchte folgendes erreichen:

1. Nur der Hauptbenutzer soll auf /mnt/data Lese- und Schreibrechte haben (700). Selbst im gemounteten Zustand soll also kein anderer User irgendwas hier dürfen. Er sieht lediglich den Ordner /mnt/data und mehr nicht.

2. Ein gewöhnlicher User soll nicht einmal mounten dürfen.

3. Selbst wenn ein User in bestimmten Gruppen ist, die mounten ermöglicht, soll er aufgrund von 1. keine Dateien sehen, öffnen, editieren etc. können.

Da ich ursprünglich davon ausgegangen bin, dass nach dem ersten Mounten der mount Ordner die üblichen 775 Berechtigungen hat und dem User gehört, der ihn gemoutet hat, könnte jeder andere die Daten zumindest lesen, aber nicht schreiben oder löschen. Daher sah ich 1. zumindest für kurze Zeit gefährdet.

Jetzt stellt sich noch die Frage: Gibt es Gruppen (außer sudo), die es dem User ermöglichen, interne und/oder externe Partitionen zu mounten und dabei automatisch den mount Ordner (oder gar die Ordner und Dateien auf der Partition) an sich zu überschreiben und/oder die Berechtigungen anzupassen? Ich hoffe einmal nicht, da das vermutlich sicherheitstechnisch problematisch wäre und außerdem 1.-3. dann so nicht umzusetzen wären ☺.

Demnach müsste folgendes Vorgehen bei einer Neuinstallation sicher sein, die Punkte 1. bis 3. erfüllen und /mnt/data so abschotten, dass jeder anderen Nutzer außer meinen Hauptnutzer keinen Zugriff auf meine Daten hat:

# Partition erstellen auf /dev/sdb1 mit ext4
# Dann:
sudo mkdir /mnt/data
sudo mount /dev/sdb1 /mnt/data      # bzw. ein entsprechender Eintrag in der /etc/fstab
                                    # der gemountete Ordner /mnt/data inkl. allem darin sollte jetzt root gehören mit 755
sudo chmod 700 /mnt/data            # jetzt kann keiner mehr in den Ordner hineinschauen
sudo chown <user>:<user> /mnt/data  # jetzt gehört der Ordner dem Hauptnutzer

Bei einer weiteren Neuinstallation braucht es (siehe oben) nur

sudo mkdir /mnt/data
sudo mount /dev/sdb1 /mnt/data      # der Ordner gehört immer noch dem Hauptnutzer mit 700

Mein Hilfsmittel wäre sonst gewesen, /dev/sdb1 weiterhin nach /mnt/data zu mounten, meine Datein aber nach /mnt/data/<user> zu packen. Das erweitert alles aber um eine weitere Ordnerschicht. 😇

guy.brush schrieb:

Erstmal vielen Dank für deine Hilfe bisher ☺.

Ja, krieg ich halt mehr Tantiemen vom Diätbuch. Passt scho ^^

Ist das richtig so? …

Stell es dir so vor: /mnt gehört deinem /. Wenn du da aber etwas mountest, liegt das auf deinem /mnt drauf und hat die Berechtigungen des Wurzelverzeichnisses vom mount. Nimmst du es wieder durch umount runter, siehst du dein altes, leeres Verzeichnis.

Beispielszenario:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

root@x220[~]› mkdir /bsp
root@x220[~]› ll -d /bsp
drwxr-xr-x 2 root root 4.0K Apr 10 20:24 /bsp
root@x220[~]› chown 1000:23456 /bsp               # Übereignung der Rechte von /bsp
root@x220[~]› ll -d /bsp                          # inklusive nicht-existente Gruppe
drwxr-xr-x 2 user 23456 4.0K Apr 10 20:24 /bsp
root@x220[~]› touch /bsp/datei
root@x220[~]› ll /bsp/datei
-rw-r--r-- 1 root root 0 Apr 10 20:25 /bsp/datei  # Datei gehört dem Ersteller!
root@x220[~]› mount /dev/sda4 /bsp
root@x220[~]› ll -d /bsp
drwxr-xr-x 21 root root 4.0K Apr 10 20:24 /bsp    # Info außerhalb
root@x220[~]› ll /bsp/
total 2.1G
drwxr-xr-x  21 root root  4.0K Apr 10 20:24 .
drwxr-xr-x  21 root root  4.0K Apr 10 20:24 ..
drwxr-xr-x   4 root root  4.0K Apr  7 18:00 boot
drwxr-xr-x   2 user 23456 4.0K Apr 10 20:25 bsp
drwxrwxr-x   2 root root  4.0K Nov  1 15:17 cdrom
drwxr-xr-x   5 root root  4.0K Jul 31  2020 dev
drwxr-xr-x 156 root root   12K Apr  7 17:59 etc
drwxr-xr-x   6 root root  4.0K Nov 30 23:24 home
…
root@x220[~]›

Ich habe den Ordner /bsp erstellt, ihn einem Nutzer und einer (nicht-existenten) Gruppe zugewiesen und danach dort eine Datei angelegt.

Wenn ich dann etwas an diesen Punkt mounte, verdeckt das die Datei im lokalen Ordner. Dadurch, dass ich mein Wurzelverzeichnis nochmal gemountet habe, siehst du aber den Ordner bsp. mit seinen ursprünglichen Berechtigungen. Er existiert also noch und hat auch die Rechte noch. Er ist nur durch den mount an der Stelle nicht mehr sichtbar.

Plugdev is meine ich ausschliesslich USB, wobei ich mir dann gerade nicht sicher bin, wieso ich dialout brauche… Muss ich noch mal nachgucken.

Ich habe alle möglichen Gruppen meines Hauptusers durchprobiert bei einem Testuser: plugdev wird definitiv nicht benötigt, aber dafür sudo! Sobald der Testuser in der Gruppe sudo ist, kann er via Dolphin interne Festplatten (alle SATA angeschlossen; externe USB-Festplatten nicht getestet) einhängen und das ohne Passwort. Ist er nicht in der sudo Gruppe, kommt ein Fenster, bei dem man ein Passwort eingeben darf. Gibt man hier das Passwort des Hauptusers (der ja in sudo ist) ein, wird erfolgreich gemountet, obwohl man eben als Testuser eingeloggt ist. Hier werden also ein paar Schritte auf einmal gemacht.

Ja, das ist abhängig vom PolicyKit. Unter anderen Systemen gibt es dann noch die Gruppen wheel und adm, falls man kein sudo installiert hat.

Im Wiki Benutzer und Gruppen (Abschnitt „Gruppen“) wird dialout für 16.04 und 18.04 mit einem roten Kreuz versehen. Vielleicht heißt das, dass man seit den Versionen die Gruppe nicht mehr benötigt für die gewünschten Aktionen?

Ich hab nur neon hier gerade. Ich brauche dialout, um auf /dev/input schreiben zu dürfen (Arduino Board). Bei arch heisst die Gruppe input, deswegen wusste ich nicht mehr, wieso dialout. War vermutlich mal die Modemgruppe.

Hmm, also ich möchte folgendes erreichen:

1. Nur der Hauptbenutzer soll auf /mnt/data Lese- und Schreibrechte haben (700). Selbst im gemounteten Zustand soll also kein anderer User irgendwas hier dürfen. Er sieht lediglich den Ordner /mnt/data und mehr nicht.

Dann müssen die gemounteten Systeme ebenfalls 1000:1000 haben (falls der Hauptnutzer das bei dir ist).

1. Ein gewöhnlicher User soll nicht einmal mounten dürfen.

Kann er nicht, wenn er nicht in den Gruppen ist oder über PolKit/UDEV die Möglichkeit hat. Da müsstest du ggf. Anpassungen vornehmen, was das Mounten von USB-Sticks, CDs, etc. angeht.

1. Selbst wenn ein User in bestimmten Gruppen ist, die mounten ermöglicht, soll er aufgrund von 1. keine Dateien sehen, öffnen, editieren etc. können.

Das ist auch so, solange er nicht in der Gruppe deines Nutzers ist. Selbst wenn er die Platte mountet, kann er nicht reingucken. Dabei ist die ursprüngliche Berechtigung von /mnt egal (siehe Beispiel oben), es geht darum, welche Rechte auf dem gemounteten Laufwerk sind. Aber: FAT & Co kennen keine Rechte. Da würde es dann ein Schlupfloch geben.

Jetzt stellt sich noch die Frage: Gibt es Gruppen (außer sudo), die es dem User ermöglichen, interne und/oder externe Partitionen zu mounten und dabei automatisch den mount Ordner (oder gar die Ordner und Dateien auf der Partition) an sich zu überschreiben und/oder die Berechtigungen anzupassen? Ich hoffe einmal nicht, da das vermutlich sicherheitstechnisch problematisch wäre und außerdem 1.-3. dann so nicht umzusetzen wären ☺.

Wie gesagt, ich habe plugdev für usb in Erinnerung. FUSE ist auch noch eine Möglichkeit, so wie NFS, Samba, etc. Ich vermute mal, dass es da Regeln im PolicyKit für gibt. Welche Gruppen die explizit anfordern: k.A. 😉 Leg nen zweiten Nutzer ohne zusätzliche Gruppen an. Sollte dann eigentlich schon passen.

Demnach müsste folgendes Vorgehen bei einer Neuinstallation sicher sein…

Müsste, ja. Ich bin mir aber nicht sicher, wie das bspw. unter GNOME ist (gvfs-mount & Co) und ob *buntus da angepasste PolicyKits mitbringen. Im neon konnte ich eben auf die schnelle nichts finden. systemd-mount ist auf jeden Fall in der Richtung richtig eingestellt und fragt per PolKit nach einem authorisierten Nutzer.

ChickenLipsRfun2eat:

Ja, krieg ich halt mehr Tantiemen vom Diätbuch. Passt scho ^^

OK, geht klar, du bekommst einen etwas größeren Anteil der Hardlinks auf die Bitcoineinnahmen 😉.

Stell es dir so vor: /mnt gehört deinem /. Wenn du da aber etwas mountest, liegt das auf deinem /mnt drauf und hat die Berechtigungen des Wurzelverzeichnisses vom mount. Nimmst du es wieder durch umount runter, siehst du dein altes, leeres Verzeichnis. [...]

Ah, du setzt praktisch nicht den Inhalt einer anderen Box (Partition) in die mount Box (Ordner), sondern ersetzt die Boxen einfach. Mit deinem Beispiel passt das so besser als das, was ich geschrieben hatte.

Fällt dir eine gute bildliche Erklärung ein, wie man sich das vorstellen kann, warum die 3 Informationen (Berechtigungen, owner, group) des äußeren Ordners/Partition/Box auch nach dem Mounten noch verfügbar sind? Ich denke hier noch zu sehr "sie müssen IN der Box sein", aber mein Modell passt da glaub nicht ganz so gut...

Er existiert also noch und hat auch die Rechte noch. Er ist nur durch den mount an der Stelle nicht mehr sichtbar.

Und nach dem unmount wieder da. Ist das "fail proof"? Sprich, darf/kann/soll man das so machen oder könnte dabei auch einmal etws schiefgehen?

Ja, das ist abhängig vom PolicyKit. Unter anderen Systemen gibt es dann noch die Gruppen wheel und adm, falls man kein sudo installiert hat.

Es ist zumindest für meinen Hauptnutzer hilfreich. Je nachdem, ob gerade in der Konsole oder in Dolphin, kommt eben sudo mount oder ein kurzer Klick zum Einsatz.

Dann müssen die gemounteten Systeme ebenfalls 1000:1000 haben (falls der Hauptnutzer das bei dir ist).

Ja, Hauptuser ist ganz klassisch 1000. Also eben chmod 1000:1000 /mnt/data, nachdem man die entsprechende Partition dort gemountet hat.

Kann er nicht, wenn er nicht in den Gruppen ist oder über PolKit/UDEV die Möglichkeit hat. Da müsstest du ggf. Anpassungen vornehmen, was das Mounten von USB-Sticks, CDs, etc. angeht. [...] Das ist auch so, solange er nicht in der Gruppe deines Nutzers ist. Selbst wenn er die Platte mountet, kann er nicht reingucken. Dabei ist die ursprüngliche Berechtigung von /mnt egal (siehe Beispiel oben), es geht darum, welche Rechte auf dem gemounteten Laufwerk sind. Aber: FAT & Co kennen keine Rechte. Da würde es dann ein Schlupfloch geben.

Gut, dann ist es sicher genug, obiges chmod auszuführen und mein Testuser kann mir nicht aus Versehen die Dateien kaputt machen 😉. Das ist mir jetzt klarer.

Wie gesagt, ich habe plugdev für usb in Erinnerung. FUSE ist auch noch eine Möglichkeit, so wie NFS, Samba, etc. Ich vermute mal, dass es da Regeln im PolicyKit für gibt. Welche Gruppen die explizit anfordern: k.A. 😉 Leg nen zweiten Nutzer ohne zusätzliche Gruppen an. Sollte dann eigentlich schon passen.

Mit PolicyKit müsste ich mich noch einmal separat später beschäftigen. Aber solange selbst mit Mountrechten nicht lesbar ist, ist alles gut ☺. Und ich brauch nicht zwangsläufig den Umweg über /mnt/data/<user>.

Müsste, ja. Ich bin mir aber nicht sicher, wie das bspw. unter GNOME ist (gvfs-mount & Co) und ob *buntus da angepasste PolicyKits mitbringen. Im neon konnte ich eben auf die schnelle nichts finden. systemd-mount ist auf jeden Fall in der Richtung richtig eingestellt und fragt per PolKit nach einem authorisierten Nutzer.

OK, gut. Problematisch würde ich es, wie gesagt, jetzt nur noch sehen, wenn ein Nutzer ohne sudo/root mounten darf und sich selbst als Eigentümer von zumindest dem gemounteten Wurzelverzeichnis setzen darf. Aber davon gehe ich jetzt einmal nicht aus.

guy.brush schrieb:

Fällt dir eine gute bildliche Erklärung ein, wie man sich das vorstellen kann, warum die 3 Informationen (Berechtigungen, owner, group) des äußeren Ordners/Partition/Box auch nach dem Mounten noch verfügbar sind? Ich denke hier noch zu sehr "sie müssen IN der Box sein", aber mein Modell passt da glaub nicht ganz so gut...

Puh… Du hast Anforderungen 😀 Du hast deine Partition / auf /dev/sda1 als deine visuell äußere Box. Dann hast du die zweite Partition / auf /dev/sdb2 als deine visuell zweite äußere Box. In Box1 befindet sich der Ordner /mnt mit den Rechten alf:alf 755. Nun möchtest du auf die Daten der zweiten Box zugreifen, also flanschst du diese an Box1 an und sagst dem System, es soll den Knotenpunkt von /mnt als Startpunkt für Box2 nehmen.
Dann kannst du dir das so vorstellen: /mnt/ ⇨ der gelb markierte ist der / von Box2. Das / von Box2 bringt eigene Berechtigungen mit. Die von Box1/mnt sind aber nicht aufgehoben, sie werden nur durch das „drankleben“ von Box2 verdeckt. Nimmst du Box2 wieder weg oder klebst Box1 noch woanders an, siehst du dessen /mnt wieder. Du ersetzt also nicht /mnt durch Box2, du gibst nur Box2 den Eingang von /mnt, welches selbst draußen bleiben muss.

Vielleicht fällt mir mal ein Apfel-Küchendurchreiche-Beispiel dafür ein, aber gerade auf Anhieb nicht. Speziell das mit dem Box1 noch mal in sich selbst anflanschen ist wieder sehr abstrakt.

Und nach dem unmount wieder da. Ist das "fail proof"? Sprich, darf/kann/soll man das so machen oder könnte dabei auch einmal etws schiefgehen?

Tja, Hausaufgabe: Lege dir mal ein paar dummy-Dateien in /mnt an, mit diversen Berechtigungen. Danach mountest du Box2 nach /mnt. Dann siehst du, was schiefgehen kann 😉 Und ja, das ist an sich „fail proof“, man kann sich aber immer irgendwie selbst in den Fuß schießen, auch wenn die Kugel dabei vorher durchs Knie muss^^ Falls du separate Einbindepunkte verwendest und nicht aus FaulheitUnwissenheit alles übereinandermountest (was geht), dann sollte auch nichts passieren, was du nicht beabsichtigt hast.

Ja, Hauptuser ist ganz klassisch 1000. Also eben chmod 1000:1000 /mnt/data, nachdem man die entsprechende Partition dort gemountet hat.

oder chmod -R, wenn die komplette Partition dem Nutzer gehören soll.

Gut, dann ist es sicher genug, obiges chmod auszuführen und mein Testuser kann mir nicht aus Versehen die Dateien kaputt machen 😉. Das ist mir jetzt klarer.

Backups solltest du trotzdem haben. Und in Ubuntu musst du aufpassen, ich meine da gibt es wenigstens automatisch Leseberechtigung, Schreibberechtigungen konnte ich hier gerade bei den Dummys nicht finden.

Mit PolicyKit müsste ich mich noch einmal separat später beschäftigen…

Oberflächlich ja. Regeln selbst erstellen ist eine gute Methode die Schärfe eines Schwertes zu testen, indem man sich selbst köpft (du magst ja metaphorische Erklärungen 😀)

Puh… Du hast Anforderungen 😀 [...]

Hehe 😇. Aber danke dir! Ich glaube, das hat noch einmal etwas geholfen ☺.

Tja, Hausaufgabe: Lege dir mal ein paar dummy-Dateien in /mnt an, mit diversen Berechtigungen. [...]

Dazu bin ich am Wochenende leider noch nicht gekommen, mache ich aber noch und frage bei Bedarf nach. Grundlegend mounte ich Sachen aber nur in leere Ordner. Alles andere wäre unbeabsichtigt.

oder chmod -R, wenn die komplette Partition dem Nutzer gehören soll.

Auch wenn /mnt/data nur aus dem Ordner data besteht und dieser sonst leer ist?

Und in Ubuntu musst du aufpassen, ich meine da gibt es wenigstens automatisch Leseberechtigung, Schreibberechtigungen konnte ich hier gerade bei den Dummys nicht finden.

Was würde automatisch Leseberichtungen geben?

Oberflächlich ja. Regeln selbst erstellen ist eine gute Methode die Schärfe eines Schwertes zu testen, indem man sich selbst köpft (du magst ja metaphorische Erklärungen 😀)

Hehe! Naja, ich würde generell keine Regeln anpassen, wenn ich nicht verstehe, was ich da mache oder der Quelle ausreichend gut vertraue ☺.

guy.brush schrieb:

Dazu bin ich am Wochenende leider noch nicht gekommen, mache ich aber noch und frage bei Bedarf nach. Grundlegend mounte ich Sachen aber nur in leere Ordner. Alles andere wäre unbeabsichtigt.

Kein Problem. Hilft dir aber beim Verstehen, was da passiert. Normalerweise mountet man auch in leere Ordner. Das eigentliche ist aber noch viel komplexer, je nachdem womit und welches Dateisystem du mountest. Also bspw. FUSE-mounts funktionieren ein wenig anders. Beim „normalen“ mount gibt es pro Dateisystem noch besondere Optionen, etc. Interessant ist noch „overlay“, weil man da Verzeichnisse zusammenführen kann, wobei eines das „obere“ Verzeichnis ist, das andere das „untere“, um zu entscheiden worein geschrieben wird und welche Datei benutzt wird, wenn sie in beiden vorkommt.

oder chmod -R, wenn die komplette Partition dem Nutzer gehören soll.

Auch wenn /mnt/data nur aus dem Ordner data besteht und dieser sonst leer ist?

Nein. Falls Daten vorhanden sind. R ist rekursiv, also steigt in eine bestehende Verzeichnisstruktur hinab und wendet das auf alle Funde an.

Was würde automatisch Leseberichtungen geben?

Die Verzeichnisse/Dateien, die du in Ubuntu anlegst haben automatisch Leseberechtigung für alle. Also 664 für Dateien und 775 für Ordner. Dafür gibt es besagte umask.

So, endlich dazu gekommen!

ChickenLipsRfun2eat

Kein Problem. Hilft dir aber beim Verstehen, was da passiert. Normalerweise mountet man auch in leere Ordner. Das eigentliche ist aber noch viel komplexer, je nachdem womit und welches Dateisystem du mountest. Also bspw. FUSE-mounts funktionieren ein wenig anders. Beim „normalen“ mount gibt es pro Dateisystem noch besondere Optionen, etc. Interessant ist noch „overlay“, weil man da Verzeichnisse zusammenführen kann, wobei eines das „obere“ Verzeichnis ist, das andere das „untere“, um zu entscheiden worein geschrieben wird und welche Datei benutzt wird, wenn sie in beiden vorkommt.

Ja, grundlegend mounte ich nur in leere Ordner. Etwas anderes würde ich nur machen, wenn ich weiß, was ich mache.

Die Verzeichnisse/Dateien, die du in Ubuntu anlegst haben automatisch Leseberechtigung für alle. Also 664 für Dateien und 775 für Ordner. Dafür gibt es besagte umask.

Ach so, ich hatte dich glaub nur falsch verstanden. Aber ja, "other" bekommen immer Leserechte. Daher setze ich mein /home stets auf 700, damit trotz der Dateiberechtigungen von 775 kein anderer User die darin enthaltenen Dateien lesen kann. Die umask habe ich hier noch nicht angepasst.

Nun zu meinen mount-Tests. Ich konnte leider keinerlei Fehler oder Merkwürdigkeit produzieren. Ich habe 2 Ordner erstellt, /mnt/foo und /mnt/bar, die beide dem test User gehören. Zu Beginn habe ich dann die Partitionen /dev/sda4 und /dev/sda5 darin gemountet:

sudo mount /dev/sda4 /mnt/foo
sudo mount /dev/sda5 /mnt/bar

Darin habe ich dann mit touch Dateien erstellt und mit chmod sowie chown Berechtigungen angepasst.

stat -c "%n %a" /mnt/foo
a 664
b 600
c 640
d 777
e 664 # chown gesetzt auf --> test:12345
f 664 # chown gesetzt auf --> 12345:67890
lost+found 700

stat -c "%n %a" /mnt/bar
1 777
2 666
3 600
4 664
5 664
b 666
lost+found 700

Dann habe ich /dev/sda5 nochmal auf den nicht-leeren Ordenr /mnt/foo gemountet und auch ein umount von /mnt/foo ausprobiert:

sudo mount /dev/sda5 /mnt/foo
sudo umount /mnt/foo

Ich habe auch mehrfach die Ordner "gestackt":

sudo mount /dev/sda5 /mnt/foo
sudo mount /dev/sda4 /mnt/foo

Was hätte ich machen müssen, um den von dir erwähnte Problemfehle zu bekommen?

guy.brush schrieb:

Nun zu meinen mount-Tests. Ich konnte leider keinerlei Fehler oder Merkwürdigkeit produzieren. … Was hätte ich machen müssen, um den von dir erwähnte Problemfehle zu bekommen?

Welches Problem hättest du denn gerne?

Zu Problemen kommt es ja meist, weil man eben problemlos „drübermounten“ kann, wenn du bspw. (per Script) zwei verschiedene Partitionen nach /mnt mountest und darauf Dateioperationen ausführst. Dazu kann man sich noch ein Bein stellen, wenn man bspw. als Nutzer ein entferntes Verzeichnis mountet und ein anderer Nutzer (mit mountoption user) oder root dann eine Partition ins entsprechende Verzeichnis mountet. Man bekommt da ja keine Information drüber, es sei denn die Berechtigungen fehlen.
Als Beispiel: Du hast ein Backupscript, das mountet automatisch und im Hintergrund alle X Stunden das Backuplaufwerk nach /mnt/backup. Nach ner Weile denkst du nicht mehr dran und mountest mal eben eine andere Platte nach /mnt, verdeckst damit das /mnt/backup,… usw. Das Backup scheitert und das bekommst du mit, wenn du dessen Logs liest. Ganz blöd isses erst, wenn in der nach /mnt gemounteten Partition ein backup-Ordner liegt und /mnt/backup damit gültig. Oder du umountest etwas, was noch da bleiben sollte… einige Systeme löschen alles unterhalb /mnt, /media beim herunterfahren.

Deswegen vermeide ich gerne /mnt, /media, usw. und lege mir eigene Ordner an. Benutzer mounten innerhalb ihres $HOME (~/Sammelmappe, ~/Zwischenlager, ~/.handy,…), backups nach /backup, backup des backups nach /bbackup, etc.