Linux: User, der keine permanenten Änderungen im Dateisystem vornehmen kann

nman schrieb:

Und für die persistenten Änderungen:

Reguläres User-Homedir irgendwo auf der HDD ablegen.

Via aufs ein tmpfs (RW) und das /home/user (RO) zusammen als /home/userdir bereitstellen.

sieht gut aus

Okay, noch ne Frage: Kann ich die Dateisysteme beim Login mounten und beom Logout wieder unmounten? Offensichtlich ist es nicht sinnvoll das als Userscript zu implementieren.

Christoph schrieb:

otze schrieb:

eventuell auch beim startup als Script einfach:

rm -rf /home/user/*
cp -r /share/usertemplate/* /home/user

Nein, das ist völlig unsicher. Um das hintergehen, muss der User einfach nur genug Dateien anlegen. Dann expandiert /home/user/* nämlich zu zu vielen Dateien, sodass die command line zu lang wird und abgeschnitten oder gar nicht erst ausgeführt wird (hoffentlich letzteres, denn wenn sie abgeschnitten wird, wird sie *natürlich* als letzten abgeschnittenen Parameter / bekommen, also rm -rf ... /).

Versteh das Problem nicht, dem Befehl
rm -rf /home/user/* sollte es doch egal sein, wieviele Dateien und Unterverzeichnisse sich in diesem Ordner befinden.

Wenn dem so nicht wäre, dann wäre das ein Bug in rm.

Ansonsten sollte es auch
rm -rf /home/user
tun, dann muss man den Ordner zwar jedesmal wieder neu anlegen, aber der Homeordner ist dann richtig frisch und die versteckten .* Dateien werden auch mitgelöscht.

Oder noch viel einfacher, der User kann Dateien anlegen, deren Name mit einem Punkt beginnt. Diese werden von * nicht erfasst.

Einfach den ganzen Ordner löschen und fertig.

@ TS

Für dein Problem gibt es in KDE den Kioskmode, der bietet so etwas in etwa an.

Christoph

Whats the problem? schrieb:

Christoph schrieb:

otze schrieb:

eventuell auch beim startup als Script einfach:

rm -rf /home/user/*
cp -r /share/usertemplate/* /home/user

Nein, das ist völlig unsicher. Um das hintergehen, muss der User einfach nur genug Dateien anlegen.

Versteh das Problem nicht, dem Befehl
rm -rf /home/user/* sollte es doch egal sein, wieviele Dateien und Unterverzeichnisse sich in diesem Ordner befinden.

rm ist an dem Problem auch völlig unschuldig. Das Problem ist das glob pattern: /home/user/* wird von der Shell expandiert zu einer Liste der ganzen Dateien und Ordner in /home/user/. Das passiert alles, bevor rm aufgerufen wird.

Nun hat die Länge einer command line aber eine obere Schranke. Wenn es zu viele Dateien gibt, wird die überschritten und rm kann nicht mehr korrekt aufgerufen werden.

Den ganzen Ordner löschen ist natürlich eine Möglichkeit, hat aber mindestens zwei Nachteile:

Man darf nicht vergessen ein user-quota zu setzen, sonst hat der User immer noch die Möglichkeit Schaden anzurichten.
Es ist auf üblichen Dateisystemen furchtbar ineffizient, bei jedem Login einen ganzen Ordner zu kopieren.

aufs hat beide diese Nachteile nicht.

Christoph schrieb:

rm ist an dem Problem auch völlig unschuldig. Das Problem ist das glob pattern: /home/user/* wird von der Shell expandiert zu einer Liste der ganzen Dateien und Ordner in /home/user/. Das passiert alles, bevor rm aufgerufen wird.

Nun hat die Länge einer command line aber eine obere Schranke. Wenn es zu viele Dateien gibt, wird die überschritten und rm kann nicht mehr korrekt aufgerufen werden.

Da wundert mich es aber dann, das so ein schwerwiegender Bug nicht abgefangen wird.

Denn die obige Kommandozeile suggeriert dem User eigentlich, daß dies alles so klappt wie er sich dachte.
Wer denkt da an ein glob Pattern Problem?

Hast du das mal in der Praxis ausprobiert und geschaut, wie sich dieser Befehl bei vielen Dateien wirklich verhält?

SeppJ

Whats the problem? schrieb:

Da wundert mich es aber dann, das so ein schwerwiegender Bug nicht abgefangen wird.

Wird er doch.

Denn die obige Kommandozeile suggeriert dem User eigentlich, daß dies alles so klappt wie er sich dachte.

Tja, dann hat der User eben keine Ahnung.

Wer denkt da an ein glob Pattern Problem?

Tja, Linux setzt eben voraus, dass man weiß, was man tut.

Hast du das mal in der Praxis ausprobiert und geschaut, wie sich dieser Befehl bei vielen Dateien wirklich verhält?

Das ist tatsächlich so. Christoph hat doch schon den möglichen Fehler erklärt. Zweifelst du an seiner Kompetenz, während du selbst offensichtlich die Problemstellung gar nicht kennst?

Christoph

Whats the problem? schrieb:

Hast du das mal in der Praxis ausprobiert und geschaut, wie sich dieser Befehl bei vielen Dateien wirklich verhält?

Ja. Bash verhält sich so, wie ich erwartet hätte:

$ find . -type f | wc -l
0
$ seq 500000 | xargs touch
$ find . -type f | wc -l
500000

Zu Beginn ist der Ordner leer. Nach dem xargs touch gibt es 500000 durchnummerierte Dateien in diesem Ordner.

$ rm *
bash: /bin/rm: Argument list too long
$ find . -type f | wc -l
500000

rm wird nicht aufgerufen, alle 500000 Dateien bleiben erhalten.

$ find . -type f -delete
$ find . -type f | wc -l
0

Mit dem find-Befehl kann man die Dateien effizient löschen.

ipsec

Whats the problem? schrieb:

Da wundert mich es aber dann, das so ein schwerwiegender Bug nicht abgefangen wird.

Denn die obige Kommandozeile suggeriert dem User eigentlich, daß dies alles so klappt wie er sich dachte.
Wer denkt da an ein glob Pattern Problem?

Dir scheinen hier Grundlagen zu fehlen. Im Gegensatz zu Windows kümmern sich Befehle wie rm nicht um irgendwelche Wildcards im Dateinamen. Stattdessen tut das die Shell: wenn ein Befehl aufgerufen werden soll, welcher Wildcards in der Command Line enthält, ersetzt die Shell den Parameter mit dem Wildcard durch die Liste passender Dateien. Also kommt bei Befehlen wie rm file* der Stern gar nicht bei rm an, sondern bevor rm überhaupt aufgerufen wird, wird der Aufruf expandiert, z.B. zu rm file1 file2 file3 . Vorteil: das Wildcard-Handling muss nicht in jedem Programm neu implementiert werden. Den Unterscheid merkst du übrigens, wenn du mal rm file\* aufrufst, dann verzichtet die Shell auf die Expansion.

Das eigentliche Problem ist nun, dass unter Linux die Command Line nur eine bestimmte Maximallänge haben darf. Und wenn bei solchen Expansionen viele Dateien betroffen sind, kann diese auch mal überschritten werden. Dafür kann die Shell aber nichts. Sie kann auch nicht einfach den Aufruf in mehrere Aufrufe aufteilen, da sie das Programm nicht kennt. Stattdessen gibt es eben einen Fehler. Möchte man tatsächlich gegebenenfalls mehrere Aufrufe, eignet sich dafür find in Verbindung mit xargs.

Christoph schrieb:

$ rm *
bash: /bin/rm: Argument list too long
$ find . -type f | wc -l
500000
rm wird nicht aufgerufen, alle 500000 Dateien bleiben erhalten.

Na dann ist doch alles in Ordnung, genau das wollte ich wissen.

Dieser am Anfang gepostete rm Befehl ist also keine unsichere Gefahr für das restliche System.

Es kann also nicht passieren, daß / gelöscht wird.

Christoph

Whats the problem? schrieb:

Es kann also nicht passieren, daß / gelöscht wird.

Ja, das wär in der Tat ein Bug in der Shell, wenn das passieren könnte. Allerdings würde ich bei rm * die Wirkung "nichts wird gelöscht" doch als "unbeabsichtigt" bezeichnen. Es führt schließlich in diesem Fall dazu, dass der User permamente Änderungen am System vornehmen kann.