debianforum.de

Hallo,

folgendes Szenario soll gelöst werden.

- Shell 1 startet ein VFS ähnlich wie EncFS um ein Verzeichnis zu entschlüsseln
- alle Child Prozesse von Shell 1 sollen auf die entschlüsselten Daten zugreifen können
- alle Prozesse aus Shell 2 sollen nicht auf die entschlüsselten Daten zugreifen können

Obiges funktioniert mit EncFS wenn die beiden Shells von unterschiedlichen Usern gestartet wurden.

Ich suche nach einer Lösung bei der dass auch funktioniert wenn beide Shells vom gleichen User gestartet wurden.

mit Gruß

SubOptimal hat geschrieben:

21.04.2021 13:39:04

Ich suche nach einer Lösung bei der dass auch funktioniert wenn beide Shells vom gleichen User gestartet wurden.

Ich behaupte mal, daß das technisch nicht umsetzbar wäre und auch keine Sinn ergäbe.

Wie willst du denn unterscheiden, daß eine zweite Shell keinen Zugriff bekommt, aber z.B. der Midnight Commander das Dateisystem anzeigen kann? mc ist auch nur ein Prozeß wie eine Shell auch.

MSfree hat geschrieben:

21.04.2021 19:39:53

Ich behaupte mal, daß das technisch nicht umsetzbar wäre und auch keine Sinn ergäbe.

umsetzbar: vermutlich ja, mit Einschränkungen
sinnvoll: eher nein

Gehen wir zur Vereinfachung mal davon aus, dass wir das Verhindern von Rootzugriffen außen vor lassen.
Du brauchst nen Treiber, der je nach anfragendem Prozess, entscheidet, ob die Dateien "da" sind oder nicht.
Ist die Anfrage nicht berechtigt, ist die Datei einfach nicht da. Will ein unberechtigter Prozess schreiben, passiert Nichts, außer return EPERM oder sowas. Sollte grundsätzlich machbar sein. Interaktion mit dem Treiber, falls notwendig, vermutlich ebenfalls, evtl via Fuse.

MSfree hat geschrieben:

21.04.2021 19:39:53

Wie willst du denn unterscheiden, daß eine zweite Shell keinen Zugriff bekommt, aber z.B. der Midnight Commander das Dateisystem anzeigen kann? mc ist auch nur ein Prozeß wie eine Shell auch.

Du könntest in der Shell, wo man den Container entschlüsselt, nen Karlklammerdienst fragen lassen:
"Darf der das? [j]a, [n]ein, [v]ielleicht."
ppid wäre das Stichwort, mit dem man an die parent pids rankommt.

Aber: da man unter X eh auf praktisch beliebige Fenster Eingaben schicken kann, bringt das Ganze eher wenig, außer evtl etwas Spaß und viele neue Erkenntnisse, während man mal versucht, das praktisch umzusetzen. Ich würde vermutlich mit nem möglichst einfachen Fuse Modul als Grundlage anfangen und dann mal schauen, wie man das mit dem Overlay am Besten hinbekommt. Freien Code für Overlay Filesysteme gibt's in mehreren Varianten, da kann man vermutlich auch ausreichend gut spicken. Die Crypto dann erst später dazubasteln (nicht selber machen, auf die bekannten Libs setzen, statisch gelinkt).

MSfree hat geschrieben:

21.04.2021 19:39:53

Ich behaupte mal, daß das technisch nicht umsetzbar wäre ...

In der Firma hatten wir mal ClearCase als Sourcecode Verwaltung und da ging es. Man hat eine View gestartet (ähnlich einer Branch in git) und die gab es nur in der Shell in der sie gestartet wurde. (das möchte ich nicht zu 100% behaupten, ist eine Weile her und ich kann es auch falsch im Gedächnis haben, aber auf dieser Erinnerung basierend habe ich gefragt).

Für prinzipiell unmögich halte ich es nicht. gvfs z.B. geht für einen User und selbst root kann nicht darauf zugreifen. Wobei es hier natürlich sehr wahrscheinlich über die User-ID gesteuert wird. Dass ist aber nicht Thema der Frage.

Danke jedenfalls.

eggy hat geschrieben:

21.04.2021 20:28:01

... Ich würde vermutlich mit nem möglichst einfachen Fuse Modul als Grundlage anfangen und dann mal schauen, wie man das mit dem Overlay am Besten hinbekommt. Freien Code für Overlay Filesysteme gibt's in mehreren Varianten, ...

Danke für deine Antwort. Aber selber bauen wollte ich nichts. Schon gar nicht den Crypto Teil.

Aber wie an @MSfree schon geantwortet, der Wunsch kann auch auf einer falschen Erinnerung basieren. Hätte für meine Zweck perfekt gepasst. Dann wird EncFS die Lösung werden.

mit Gruß

n der Firma hatten wir mal ClearCase als Sourcecode Verwaltung und da ging es.

Da ist das aber mehr Bug als Feature. Die speichern ihren State (wie das sehr üblich ist) halt in der Umgebung. Entsprechend funktioniert das natürlich nur in der Umgebung und da die in alle Kind Prozesse weiterkopiert wird auch da. Selbstverständlich kann jeder andere Benutzer (und selbstverständlich root) munter die Umgebung von Hand kopieren. Beispielswese über cat /proc/[PID]/environ und export. Du kannst jetzt natürlich das proc Dateisystem nur als root lesbar machen. Dann nimmt der halt gdb oder leitet die ein und Ausgaben wie eggy Vorgeschalgen hat um.

Lasst den scheiß einfach. Du kannst entweder das Rechtemanagement, dass dir dein OS gibt verwenden oder Sicherheit sein lassen. Es gibt gerade für Windows einen riesen haufen von Firmen, die dir da was anderes verkaufen. Es ist immer Bullshit. Du hast einfach mal ein paar Milliarden Zeilen Code die darauf ausgelegt sind das alles schön zusammen arbeitet. Da jede nochmal zu kontrollieren und vor allem jede im Zusammenhang mit anderen kannst du vergessen. Und entsprechend wir jeder der sucht da irgend wo fündig werden. Docker hat das eventuell ansatzweise gemacht. Aber Docker Inc hat alleine $100 Mio. in Etwickler gesteckt und viel Hilfe aus dem Kernelentwicklerteam bekommen, die diverse Änderungen am Kernel gemacht haben. (Und vor allem schon zuvor in Form von Namespaces and chroots gemacht haben.)
Ganz sicher zieht nicht der Admin Superschlau oder die Softwareklitsche von nebenan.