[gelöst]Mounten von $USER/.cache nach /tmp via systemd

[Artim]

Hallo,
ich bräuchte ein wenig hilfe bei folgendem Problem: ich habe auf unserem Computer (Debian testing Zweig) schon /tmp in eine RAM-Disk gepackt. Nun würden wir gerne auch die .cache Ordner der Nutzer dort hin verschieben, um die notwendigen Schreibzugriffe auf die Festplatte zu reduzieren (weiß nicht ob es Sinn macht auch /var/cache und /var/tmp dort hin zu schieben oder ob dort Dateien liegen, die einen reboot überstehen sollen). Da wir nicht gerade wenige Nutzer haben, sollte das also automatisiert ablaufen. Außerdem muss es auf jeden Fall nach fstab ausgeführt werden, da bei uns /home/ nicht lokal auf dem Computer liegt, sondern per nfs von einem Server gemounted wird.
Es sieht zumindest so aus, als wären systemd mount units dafür geeignet, aber so ganz verstehe ich noch nicht was alles für diesen Zweck dort stehen muss. Was ich mir vorgestellt habe ist etwas in diese Richtung:

Code: Alles auswählen

[Unit]
Description=Mount Nutzer-Cache nach tmp

[Mount]
What=/home/$USER/.cache
Where=/tmp/$USER/
Type=?
Options=?
LazyUnmount=yes(?)

[Install]
WantedBy=?

Kann jemand beurteilen, ob das vorhandene so passt und wie die Lücken zu füllen wären? Bei Options würde ich vermutlich einfach rein schreiben, was in fstab bereits für die ramdisk definiert ist: noexec,noatime,defaults,nodev,nosuid,mode=1777,size=1G (vermutlich ohne mode und size). Aber ich weiß nicht, ob das What und Where so aufgeht (also es soll quasi die .cache Ordner nehmen und als /tmp/$USER/.cache mounten). Und ich weiß nicht, welcher Typ sich da eignen würde und vor allem, ob und was man noch in der Install Sektion braucht

[TomL]

Da wir nicht gerade wenige Nutzer haben, sollte das also automatisiert ablaufen. Außerdem muss es auf jeden Fall nach fstab ausgeführt werden, da bei uns /home/ nicht lokal auf dem Computer liegt, sondern per nfs von einem Server gemounted wird.

Das ist während des System-Starts (also in der gesamte Boot-Phase) eigentlich nicht möglich, weil ja zu dem Zeitpunkt noch gar nicht bekannt ist, welcher User sich anmelden wird. Wie ist das mit den Homedirs geregelt, die ja auch erst dann passieren dürfen, wenn das Netzwerk verbunden ist und bekannt ist, welches Homedir für welchen User auf diesem speziellen PC gemountet werden soll? Wie das mit dem "automatisiert" gedacht ist, habe ich noch nicht so recht verinnerlicht... eben weil sich ja durchaus nacheinander unterschiedliche User aus einer Anzahl von Vielen anmelden könnten und für jeden User individuelle Mounts notwendig sind.

[JTH]

um die notwendigen Schreibzugriffe auf die Festplatte zu reduzieren

Vorweg: Ich bin mir nicht ganz sicher, obs das wert ist. Andersherum müssen manche Dateien, die nach nem Reboot damit verloren gehen, jedesmal neu erzeugt werden – das macht die Benutzung für den Benutzer womöglich zäher.

weiß nicht ob es Sinn macht auch /var/cache und /var/tmp dort hin zu schieben oder ob dort Dateien liegen, die einen reboot überstehen sollen

/var/tmp ist laut FHS tatsächlich für persistente temporäre (sic!) Dateien gedacht, die Reboots eher überstehen sollen. /var/cache soll auch Dateien enthalten, die zeitaufwendiger neu zu generieren sind; vermutlich ebenfalls nicht sinnvoll, das immer wegzuwerfen.

Es sieht zumindest so aus, als wären systemd mount units dafür geeignet, aber so ganz verstehe ich noch nicht was alles für diesen Zweck dort stehen muss. Was ich mir vorgestellt habe ist etwas in diese Richtung:

Wie Thomas denke ich, dass das per Mounts nicht sinnvoll zu lösen ist. Einen generischen Weg (mit Variablen) als Benutzer nur mit Benutzerrechten gibts wegen eben der Berechtigungen nicht direkt. Man müsste es also für jeden Benutzer in die fstab eintragen oder für jeden Benutzer mount-Units erzeugen.

Ne andere, ziemlich simple Idee wäre ein Symlink ~/.cache -> /tmp/user-cache-Artim. Das ist ziemlich simpel mit 2 Zeilen für systemd-tmpfiles für alle Benutzer zu lösen:

Code: Alles auswählen

$ cat /usr/local/share/user-tmpfiles.d/user-cache-dir.conf
# Type	Path			Mode	User	Group	Age	Argument
d	%T/user-cache-%u	-	-	-	-	-
L+	%C			-	-	-	-	%T/user-cache-%u

plus einmalig – wichtig mit --global –

Code: Alles auswählen

# systemctl --global enable systemd-tmpfiles-setup.service systemd-tmpfiles-clean.timer

Namen des Ordners unter /tmp, hier /tmp/user-cache-$USER, kannst du je nach Belieben anpassen und evtl. die Lesbarkeit einschränken, wäre hier default 0755. Obwohl das ja auch die übliche Berechtigung für $HOME ist.

Der Ordner in /tmp und der Symlink werden von systemd-tmpfiles beim Einloggen eines Benutzers angelegt, falls sie noch nicht existieren. Ein schon existierender Ordner ~/.cache wird dabei gelöscht.

[TomL]

Einen generischen Weg (mit Variablen) als Benutzer nur mit Benutzerrechten gibts wegen eben der Berechtigungen nicht direkt. Man müsste es also für jeden Benutzer in die fstab eintragen oder für jeden Benutzer mount-Units erzeugen.

Für normale Netzwerk-Shares ist es kein großes Problem, diese generisch für den User zu erzeugen. Ich habe nur keine Vorstellung, wie das mit dem User-Homedir möglich ist, weil ich keine Vorstellung vom Timing des Anmeldeablaufs hinsichtlich des dafür möglicherweise notwendig verfügbaren Homedirs habe. Also, wenn oder während PAM-Login läuft, würde es ja noch kein Homedir geben. Ich weiss nicht, ob es da Konflikte wegen zu spät erfüllter Verfügbarkeit mit der X-Session gibt.

Ich müsste das morgen mal testen... und die Verfügbarkeit des Homedir etwas verzögern.... ob die X-Session für den User damit klar kommt oder ob sogar auf beendetes PAM-Login gewartet wird.

[JTH]

Wie mountest du denn die Home-Ordner von Remote, Thomas – pam_mount?

Ich hab mit dem Schlagwort PAM aus Interesse grad mal geschaut, wie sich die Ursprungsfrage hier noch lösen ließe, und bin über pam_mount gestolpert (hab mich noch nie näher mit PAM beschäftigt).

Damit wärs wohl noch besser lösbar:
libpam-mount installieren, pam_mount.so entsprechend der manpage in /etc/pam.d/login (evtl. ists in common-auth und common-session sinnvoller)[macht das Paket selbst bei Installation] ergänzen und eine einzige Zeile in /etc/security/pam_mount.conf.xml ergänzen:

Code: Alles auswählen

<volume fstype="tmpfs" path="tmpfs" mountpoint="~/.cache" options="uid=%(USERUID),mode=0700" />

Cool

Auf diesem Weg kann der Benutzer nicht verhindern, dass ~/.cache ein tmpfs ist – einen Symlink wie oben könnte man einfach löschen.

Mit dem pam_mount lässt sich $HOME mounten, scheint der eigentliche Anwendungszweck zu sein. Mit richtiger Reihenfolge der Volumes in der pam_mount.conf.xml klappts mit Mointpoint im Mountpoint.

Wieder was gelernt

[Artim]

Wie das mit dem "automatisiert" gedacht ist, habe ich noch nicht so recht verinnerlicht... eben weil sich ja durchaus nacheinander unterschiedliche User aus einer Anzahl von Vielen anmelden könnten und für jeden User individuelle Mounts notwendig sind.

Ich glaube du denkst da viel zu kompliziert. Es ist ein ganz simples

Code: Alles auswählen

example.de:/home	/home	nfs	users,x-systemd.automount,fsc,x-systemd.device-timeout=10,timeo=14,noatime	0 0

in fstab. Und sobald das gemounted ist, sollen einfach die .chache aller Nutzer nach /tmp gehängt werden. Im idealfall inklusive automatischer Bereinigung, da die RAM-Disk nur mit 1 GB vorgesehen ist und zumindest jetzt noch haufenweise zeug dort liegt, sodass mein .chache alleine z.B. schon 1,3 GB belegen würde.

Ich kann aus dem Kopf nur sagen, dass es an sich möglich ist, da wir es schon zu laufen hatten, als wir für kurze Zeit Ubuntu zu laufen hatten. Nur habe ich da nicht nachgeschaut, wie das gelöst wird und der Admin, der das damals gemacht hat, weiß es auch nicht mehr, hatte aber die systemd mount units vorgeschlagen.

Ach ja, ich weiß nicht ob es relevant ist, aber die Nutzerverwaltung läuft bei uns über openLDAP, pam ist also ohnehin schon in benutzung. k.a. ob das evtl. für pam_mount spricht. Muss mir das mal in Ruhe anschauen, wenn ich Zeit habe

[JTH]

Code: Alles auswählen

example.de:/home	/home	nfs	users,x-systemd.automount,fsc,x-systemd.device-timeout=10,timeo=14,noatime	0 0

Die Option users beim fstab-Eintrag für /home ist ziemlich böse – und nicht nötig. Damit kann ein beliebiger Benutzer nach Anmeldung /home unmounten …

Code: Alles auswählen

~$ mount | grep home
systemd-1 on /home type autofs (rw,relatime,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10121)
/dev/vdb1 on /home type ext4 (rw,nosuid,nodev,noexec,relatime,x-systemd.automount)
~$ cd /
/$ umount /home
/$ mount | grep home
systemd-1 on /home type autofs (rw,relatime,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10121)

Für x-systemd.automount ist users außerdem nicht nötig, das läuft im PID-1-Kontext

Ich denke, du wirst mit systemd-Mount-Units nicht zum Ziel kommen. Die sind meine ich im User-Kontext nicht möglich (mangels Berechtigungen, m.W.n. nicht zu umgehen), müssten also in einem der systemweiten Pfade liegen. Gleichzeitig können Mount-Units keine Template-Units sein und dürfen im Pfad des Mointpoints (Where=/home/user/.cache) keine Variablen enthalten. Du müsstest also tatsächlich für alle Benutzer die Mount-Unit generieren (user-cache-alice.mount, user-cache-bob.mount, user-cache-carol.mount etc.), anstatt das über einen einmaligen, generischen Konfigurationsweg zu lösen. Ist natürlich möglich, aber unnötiger extra Aufwand und Fehlerquelle.

pam_mount unterstützt auch Bind-Mounts (~.cache -> /tmp/xyz) oder natürlich bei separatem tmpfs pro /home/X/.cache eine Größenbeschränkung auf 1GiB o.ä.

[TomL]

Die Option users beim fstab-Eintrag für /home ist ziemlich böse – und nicht nötig. Damit kann ein beliebiger Benutzer nach Anmeldung /home unmounten …

Das ist meiner Meinung nach vor dem Hintergrund, wie ich die tatsächlichen Absichten nun vermute, eigentlich völlig unkritisch. Aber im Moment viel wichtiger ist meine Befürchtung total danebenzuliegen... denn mittlerweile glaube ich sogar, dass wir vielleicht die Intention an sich missverstanden haben.
Ich bin bisher davon ausgegangen, wenn man von Homedir im LAN spricht, dass i.ü.S. "/home/thomas" erfolgreich aufs Netzwerk gemountet ist, wenn ich mich angemeldet habe, so das mir meine Dateien zur Verfügung stehen Aber scheinbar stimmt das gar nicht. Er mountet offensichtlich nicht "/home/thomas", sondern nur "/home" und hat damit 10, 100 oder 1000 User-Homedirs auf dem PC als Verzeichnisse auf einem Share-LAN-Storage sichtbar. Der dann folgende Zugriff auf die darin liegenden persönlichen User-Homedirs ist irgendwie anders geregelt.... keine Ahnung wie genau.

Insofern sollte es da egal sein, ob "users" als Mount-Option enthalten ist oder nicht ... er will ja anscheinend eh immer alle Homedirs sehen und die Rechtefrage auf die darin liegenden tatsächlichen User-Homedirs ist offensichtlich geklärt. *hmmm*

Ich denke, du wirst mit systemd-Mount-Units nicht zum Ziel kommen. Die sind meine ich im User-Kontext nicht möglich

Das ist richtig... aber es würde mit instantiierten Service-Units gehen. So mach ich das eigentlich schon seit Jahren. Allerdings erfolgen bei mir die Mounts tatsächlich generisch erst nach der User-Anmeldung... wenn ich weiss, wer der User ist und dann genau das, was für diesen User notwendig ist.

pam_mount unterstützt auch Bind-Mounts

pam-mounts erkennen zwar den User, aber nicht, ob das Netzwerk überhaupt verfügbar ist. Das ist dann relevant, wenn man auch mobile Geräte einsetzt, die nicht immer unbedingt das richtige Netzwerk ordentlich verbunden vorfinden. Insofern habe ich das mit den pam-mounts und den schwächeren generischen Möglichkeiten schon vor langem wieder verworfen.

Ich weiss nicht, ob man das hier lösen kann, solange man das dahinterstehende Konzept nicht richtig verstanden hat. Einfach mal ein paar Mounts zu entwerfen, ohne die tatsächlichen Abhängigkeiten zu kennen, scheint mir ein riskantes Vorhaben.

[JTH]

Auch wenns inzwischen ein bisschen von der eigentlichen Frage weggeht:

Das ist meiner Meinung nach vor dem Hintergrund, wie ich die tatsächlichen Absichten nun vermute, eigentlich völlig unkritisch.

Findest du? Ich sehe das eher genau andersherum: Wenn ein Benutzer nur sein eigenes /home/hanswurst unmounten kann, hat das nicht so viel Problempotenzial, wie wenn ein Benutzer das ganze /home umounten kann. Beides ist hier tatsächlich vermutlich unkritisch – durch das x-systemd.automount wird /home, falls von einem Benutzer geunmountet, direkt wieder eingebunden.

Ich wär mit solchen unnötigen, zusätzlichen Berechtigungen trotzdem vorsichtig. Und notwendig ist das users – soweit wir das verstanden haben – hier nicht. Das x-systemd.automount deckt schon ab, das /home gemountet wird, sobald es gebraucht wird.

Ohne x-systemd.automount könnte ein Benutzer durch die users-Option hier aber für andere Benutzer beliebig merkwürdiges Verhalten produzieren.

Das ist richtig... aber es würde mit instantiierten Service-Units gehen. So mach ich das eigentlich schon seit Jahren. Allerdings erfolgen bei mir die Mounts tatsächlich generisch erst nach der User-Anmeldung... wenn ich weiss, wer der User ist und dann genau das, was für diesen User notwendig ist.

Nur so aus Interesse: Hast du das irgendwo beschrieben? Du hast ja manche Projekte dokumentiert

pam-mounts erkennen zwar den User, aber nicht, ob das Netzwerk überhaupt verfügbar ist. Das ist dann relevant, wenn man auch mobile Geräte einsetzt, die nicht immer unbedingt das richtige Netzwerk ordentlich verbunden vorfinden.

Okay, für mobilere Geräte passt das natürlich nicht zwangsläufig. Für ein fixes, lokales Netz scheint mir pam_mount aber der simpelste Weg, mit der wenigsten Folge-/Wartungsarbeit. Wie löst du es, wenn kein Netzwerk verfügbar ist? Scheitert dann die Anmeldung? – das müsste doch auch mit pam(_mount) möglich sein. In dem Moment mit dem richtigen Netzwerk verbinden geht aber wohl über den Scope von PAM hinaus.

Einfach mal ein paar Mounts zu entwerfen, ohne die tatsächlichen Abhängigkeiten zu kennen, scheint mir ein riskantes Vorhaben.

Man kanns ja mal versuchen Und da hier ja nur lokal ge(bind)mountet werden soll, scheint mir die Netzwerkverfügbarkeit nicht so kritisch.

[TomL]

Auch wenns inzwischen ein bisschen von der eigentlichen Frage weggeht:

Das Thema ist aber äußerst spannend und ich finde, dass das auch noch zusammenpasst.... zumindest, weil das ja alles zusammenhängt.

Also... ich habe heute morgen mal ein wenig experimentiert und herausgefunden, dass das prima klappt. Ich kann sowohl ein exklusives User-Home-Dir als auch ganz normale Samba-Shares komplett individuell und generisch genau für einen User mounten. Das bedeutet, egal wieviel User sich im Laufe eines Tages an diesem System anmelden, jeder User findet genau sein Homedir und sein Daten vor. Und es bedeutet, dass alle Zugriffe ganz konkret an die persönlichen Rechte dieses User gebunden sind.... so wie sie zentral auf dem Server unter Linux und für Samba vergeben sind.

Es gab allerdings 2 Probleme. Das erste hängt mit dem Sound zusammen. Pulseaudio wird offensichtlich parallel im Anmeldeprozess verarbeitet, so dass die Sound-Settings lokal in ~/.config/pulse lagen, und zwar bevor das homedir vom Server gemountet war. Das funktionierte trotzdem, weil die Filehandles ja trotz drüber-mounten leben, ist aber dennoch eine total unsaubere Situation. Ich konnte das mit 'nem dirty-hack lösen, in dem ich kurzerhand aus /etc/xdg die pulseaudio.desktop entfernt habe. Die müsste dann in den Autostart im homedir ...habe ich aber nicht gemacht, weils mir gereicht hat, den Fehler zu beseitigen. Das weitere wäre ja nur wieder Funktion wiederherstellen. Aber darum gings ja nicht. Bei der nächsten Anmeldung war also alles, wie es soll... homedir plus andere mounts userindividuell erfolgreich vom Server.

Das zweite Problem war (wobei ich nicht weiss, ob man das überhaupt als Problem sehen muss), dieses Server-Homedir ließ sich bei Abmeldung des Users nicht wieder unmounten.... laufende Prozesse *hmmm*. Möglicherweise ist das bei entsprechenden Rechten aber gar kein Problem, weil lokale Homedirs ja auch immer lokal existieren. Ich habe mich deshalb nicht weiter damit befasst.

Aber prinzipiell konnte ich feststellen, dass das Mounten komplett generisch funktioniert.

Findest du? Ich sehe das eher genau andersherum:

Du hast Recht... das ist 'ne völlig überflüssige Problemquelle.... kann man einfach vermeiden... und zwar ohne "users"

Nur so aus Interesse: Hast du das irgendwo beschrieben? Du hast ja manche Projekte dokumentiert

Ja, sicher... umfangreich sogar... in drei Steigerungsstufen bezogen auf die Anforderungen. Mit der letzten Stufe habe ich das jetzt getetstet, was relativ einfach war.... einfach nur einen zusätzlichen expliziten Service-Unit-Start (aus zeitlichen Gründen im Ablauf explizit vor der Normalverarbeitung) aufs Homedir mit dem Usernamen als Instanz-Parameter eingetragen und rennt....

Okay, für mobilere Geräte passt das natürlich nicht zwangsläufig. Für ein fixes, lokales Netz scheint mir pam_mount aber der simpelste Weg, mit der wenigsten Folge-/Wartungsarbeit. Wie löst du es, wenn kein Netzwerk verfügbar ist? Scheitert dann die Anmeldung?

Nööö, es wird gar nicht erst gemountet. Ist dort auch beschrieben... *fg*

Das ist insgesamt ein abgestimmtes Verfahren auf bestimmte Situationen: lokale Anmeldung mit Netz, fremde AP-Anmeldung ohne mein Netz, fremde-AP-Anmeldung mit Netz via OpenVPN. Dazu gehören generische Mounts, wie auch generische und persistente Netzwerk-Verbindungen.

In dem Moment mit dem richtigen Netzwerk verbinden geht aber wohl über den Scope von PAM hinaus.

Das kann PAM nicht... die Schwächen von PAM, Networkmanager, DHCPD, systemd-networkd und warum keines von denen für bestimmte Situationen für meine Anforderungen auf "einfachster Bedienkomfort" tauglich ist, habe ich dort auch beschrieben.

[Artim]

Wie mountest du denn die Home-Ordner von Remote, Thomas – pam_mount?

Ich hab mit dem Schlagwort PAM aus Interesse grad mal geschaut, wie sich die Ursprungsfrage hier noch lösen ließe, und bin über pam_mount gestolpert (hab mich noch nie näher mit PAM beschäftigt).

Damit wärs wohl noch besser lösbar:
libpam-mount installieren, pam_mount.so entsprechend der manpage in /etc/pam.d/login (evtl. ists in common-auth und common-session sinnvoller)[macht das Paket selbst bei Installation] ergänzen und eine einzige Zeile in /etc/security/pam_mount.conf.xml ergänzen:

Code: Alles auswählen

<volume fstype="tmpfs" path="tmpfs" mountpoint="~/.cache" options="uid=%(USERUID),mode=0700" />

Cool

Auf diesem Weg kann der Benutzer nicht verhindern, dass ~/.cache ein tmpfs ist – einen Symlink wie oben könnte man einfach löschen.

Mit dem pam_mount lässt sich $HOME mounten, scheint der eigentliche Anwendungszweck zu sein. Mit richtiger Reihenfolge der Volumes in der pam_mount.conf.xml klappts mit Mointpoint im Mountpoint.

Wieder was gelernt

Ich habe mich jetzt mal an pam_mount versucht, aber es scheint daran zu scheitern es auch tatsächlich aufzurufen (und ggf nach logout wieder auszuhängen).
Mein Eintrag sieht zwar etwas anders aus, sollte aber eigentlich seinen Zweck erfüllen, k.a. ob dein Ansatz das gleiche bewirkt, aber ich wäre zumindest nicht scharf drauf ein zweites tmpfs aufzumachen, wir haben "nur" 8 GB RAM:

Code: Alles auswählen

<volume path="/home/%(USER)/.cache" mountpoint="/tmp/" options="bind" />

Das habe ich einfach unter <!-- Volume definitions --> gesetzt.
Allerdings sehe ich kein Anzeichen, dass .cache dort wirklich eingehängt wird, wenn ich mich einlogge. Die in der man page erwähnte Datei /etc/pam.d/service existiert gar nicht erst. Habe ich irgendwo einen Hebel übersehen?

[TomL]

Du hast 'pam-mount' in der PAM-Infrastruktur registriert und aktiviert?

[Artim]

Du hast 'pam-mount' in der PAM-Infrastruktur registriert und aktiviert?

Nein. Die frage ist halt wo genau? /etc/pam.d/service aus der man page existiert ja gar nicht erst. Und in /etc/pam.d/login weiß ich nicht, an welche Stelle das rücken müsste. Und JTH meinte ja dass das Paket das selbst machen würde.

[TomL]

Welche Optionen bietet

Code: Alles auswählen

# pam-auth-update

?

[Artim]

Welche Optionen bietet

Code: Alles auswählen

# pam-auth-update

?

Code: Alles auswählen

[|] Unix authentication
[*] Mount volumes for user
[*] LDAP Authentication
[*] Register user sessions in the systemd control group hierarchy
[ ] Create home directory on login
[ ] GNOME Keyring Daemon - Login keyring management

Sieht also für mich so aus als wäre es schon aktiv

[JTH]

Und JTH meinte ja dass das Paket das selbst machen würde.

Ja, das tut es (zumindest in meiner VM), war mir vorher nicht bewusst:

Code: Alles auswählen

$ grep -r pam_mount /etc/pam.d
/etc/pam.d/common-session:session	optional	pam_mount.so 
/etc/pam.d/common-password:password	optional	pam_mount.so disable_interactive
/etc/pam.d/common-auth:auth	optional	pam_mount.so

Mein Eintrag sieht zwar etwas anders aus, sollte aber eigentlich seinen Zweck erfüllen, k.a. ob dein Ansatz das gleiche bewirkt, aber ich wäre zumindest nicht scharf drauf ein zweites tmpfs aufzumachen, wir haben "nur" 8 GB RAM:

Code: Alles auswählen

<volume path="/home/%(USER)/.cache" mountpoint="/tmp/" options="bind" />

Das habe ich einfach unter <!-- Volume definitions --> gesetzt.

Okay, dann passt ja der Bind-Mount. Die Stelle in der pam_mount.xml passt.

Du hast allerdings die Argumente verdreht: Mountpoint sollte ~/.cache sein, zu mountender Pfad /tmp/…. So wie du geschrieben hast, würdest du allerdings das komplette /tmp bind-mounten. Ist das wirklich gewollt? Das dürfte ziemlich leicht zu Datenleaks und -konflikten führen, wenn mehr als ein Benutzer gleichzeitig oder nacheinander angemeldet sind.

Ich denke, ein Unterordner in /tmp ist sinnvoller:

Code: Alles auswählen

<volume path="/tmp/user-%(USER).cache" mountpoint="~/.cache" options="bind" />

pam_mount legt den Ordner in /tmp allerdings nicht an. Das könnte man über ein kleines Skript lösen:

Code: Alles auswählen

$ cat /usr/local/bin/pam-mkusercache
#!/bin/sh
set -eu

user_cache_dir="/tmp/user-${PAM_USER}.cache"

case "$PAM_TYPE" in
	open_session)
		/bin/mkdir -m0700 -p "$user_cache_dir"
		/bin/chown "${PAM_USER}:${PAM_USER}" "$user_cache_dir"
		;;
	close_session)
		# Optional: Cache leeren, wenn Benutzer *komplett* abgemeldet.
		login_count="$(/usr/sbin/pmvarrun -u "$PAM_USER" -o 0)"
		if [ "$login_count" -eq 1 ]; then
			/bin/rm -fr "$user_cache_dir/"*
		fi
		;;
esac

plus die Zeile

Code: Alles auswählen

session	optional	pam_exec.so /usr/local/bin/pam-mkusercache
session	optional	pam_mount.so

über der pam_mount-Zeile in /etc/pam.d/common-session.

Das ganze gilt auch für /root/.cache – falls das ausgenommen sein soll, kann man das in pam_mount.conf.xml und im Skript ergänzen.

[TomL]

Ich denke, ein Unterordner in /tmp ist sinnvoller:

Code: Alles auswählen

<volume path="/tmp/user-%(USER).cache" mountpoint="~/.cache" options="bind" />

Obwohl das eigentlich richtig ist, ist imho trotzdem noch ein Flüchtigkeitsfehler enthalten.... und zwar sind an dieser Stelle relative Pfade nicht die sichere Methode, weil man davon ausgehen kann, dass hier noch kein Kontextwechsel auf den User durchgeführt ist, sondern "root" am werkeln ist.

Code: Alles auswählen

    <volume path="/tmp/%(USER)"   mountpoint="/home/%(USER)/.cache"   options="bind" />

Ich würde ja gerne mal die ganze pam_mount.conf.xml sehen, um zu prüfen, ob die tatsächlich korrekt ist... hier funktioniert das mit dem Bind des User-.cache-Dirs nach /tmp wirklich tadellos.

[Artim]

Ich denke, ein Unterordner in /tmp ist sinnvoller:

Code: Alles auswählen

<volume path="/tmp/user-%(USER).cache" mountpoint="~/.cache" options="bind" />

Obwohl das eigentlich richtig ist, ist imho trotzdem noch ein Flüchtigkeitsfehler enthalten.... und zwar sind an dieser Stelle relative Pfade nicht die sichere Methode, weil man davon ausgehen kann, dass hier noch kein Kontextwechsel auf den User durchgeführt ist, sondern "root" am werkeln ist.

Code: Alles auswählen

    <volume path="/tmp/%(USER)"   mountpoint="/home/%(USER)/.cache"   options="bind" />

Ich würde ja gerne mal die ganze pam_mount.conf.xml sehen, um zu prüfen, ob die tatsächlich korrekt ist... hier funktioniert das mit dem Bind des User-.cache-Dirs nach /tmp wirklich tadellos.

Wie genau stelle ich den Kontextwechsel her?

https://pastebin.com/Gkq4ksbc
Hier die gewünschte Datei mit den Anmerkungen von JTH

[TomL]

https://pastebin.com/Gkq4ksbc

Ich hatte mir den Grund schon gedacht, warum das so nicht funktioniert. Vergleich einfach mal das, was an "mntoptions allow" erlaubt ist und was Du tatsächlich verwendest.

Wie genau stelle ich den Kontextwechsel her?

Das ist überhaupt nicht notwendig und ich würde das auch nicht so kompliziert angehen. Das geht imho einfacher, ohne erst noch sinnlos einen Mountpoint einzurichten... den gibt es doch bereits bei bestehenden Usern... und wenn nicht, sollte der eigentlich laut conf automatisch angelegt und auch wieder entfernt werden.

So sieht das hier im Test aus, allerdings nur an den User "inet" als Testuser gebunden... aber das kann man ja entfernen:

Code: Alles auswählen

# ls -lah /etc/security/pam_mount.conf.xml
    -rw-r--r-- 1 root root 532 2020-01-14 16:27 /etc/security/pam_mount.conf.xml

# cat /etc/security/pam_mount.conf.xml
    <?xml version="1.0" encoding="utf-8" ?>
    <!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">

    <pam_mount>
        <debug enable="0" />
        <volume user="inet" fstype="tmpfs" mountpoint="/home/%(USER)/.cache"   options="mode=700,uid=%(USER),strictatime,noexec,nosuid,nodev" />

        <mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other,bind,mode,strictatime" />
        <mntoptions require="" />
        <logout wait="0" hup="no" term="no" kill="no" />

        <mkmountpoint enable="1" remove="true" />
    </pam_mount>

[JTH]

Obwohl das eigentlich richtig ist, ist imho trotzdem noch ein Flüchtigkeitsfehler enthalten.... und zwar sind an dieser Stelle relative Pfade nicht die sichere Methode, weil man davon ausgehen kann, dass hier noch kein Kontextwechsel auf den User durchgeführt ist, sondern "root" am werkeln ist.

~ verhält sich in der pam_mount.conf.xml wie mans naiv erwarten würde:

"~" expands to the user's home directory as present in the passwd database, according to sh semantics.

pam_mount legt, falls nicht vorhanden, den mit mountpoint="…" angegebenen Pfad an. Was es nicht anlegt, ist der Pfad unter /tmp der dahin ge-bind-mountet werden soll. Deshalb mein obiger Vorschlag mit pam_exec, um ein mkdir /tmp/… aufrufen zu können. Der hat, ohne weitere Änderungen, in einer sauberen VM-Spielwiese so funktioniert:

libpam-mount installiert, eine Zeile extra in /e/s/pam_mount.conf.xml und eine in /e/p.d/common-session und nen ausführbares Skript nach /usr/local/bin/pam-mkusercache.

[Artim]

https://pastebin.com/Gkq4ksbc

Ich hatte mir den Grund schon gedacht, warum das so nicht funktioniert. Vergleich einfach mal das, was an "mntoptions allow" erlaubt ist und was Du tatsächlich verwendest.

Wie genau stelle ich den Kontextwechsel her?

Das ist überhaupt nicht notwendig und ich würde das auch nicht so kompliziert angehen. Das geht imho einfacher, ohne erst noch sinnlos einen Mountpoint einzurichten... den gibt es doch bereits bei bestehenden Usern... und wenn nicht, sollte der eigentlich laut conf automatisch angelegt und auch wieder entfernt werden.

So sieht das hier im Test aus, allerdings nur an den User "inet" als Testuser gebunden... aber das kann man ja entfernen:

Code: Alles auswählen

# ls -lah /etc/security/pam_mount.conf.xml
    -rw-r--r-- 1 root root 532 2020-01-14 16:27 /etc/security/pam_mount.conf.xml

# cat /etc/security/pam_mount.conf.xml
    <?xml version="1.0" encoding="utf-8" ?>
    <!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">

    <pam_mount>
        <debug enable="0" />
        <volume user="inet" fstype="tmpfs" mountpoint="/home/%(USER)/.cache"   options="mode=700,uid=%(USER),strictatime,noexec,nosuid,nodev" />

        <mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other,bind,mode,strictatime" />
        <mntoptions require="" />
        <logout wait="0" hup="no" term="no" kill="no" />

        <mkmountpoint enable="1" remove="true" />
    </pam_mount>

Danke das läuft jetzt. Hab halt noch eine Größenbegrenzung eingefügt und die bereits vorhandene ramdisk auf 128M begrenzt. Habe nicht das gefühl dass in /tmp je mehr als ein paar kB liegen

PS: kann man Themen hier auch als gelöst markieren?

[JTH]

Okay, das ist dasselbe, was ich vor 5 Tagen mal vorgeschlagen hatte

PS: kann man Themen hier auch als gelöst markieren?

Du kannst den ersten Beitrag bearbeiten und ein „[gelöst]“ im Titel anhängen.

[Artim]

Okay, das ist dasselbe, was ich vor 5 Tagen mal vorgeschlagen hatte

PS: kann man Themen hier auch als gelöst markieren?

Du kannst den ersten Beitrag bearbeiten und ein „[gelöst]“ im Titel anhängen.

Danke. Das Bearbeiten meines OP wurde eben nicht angeboten...

[TomL]

~ verhält sich in der pam_mount.conf.xml wie mans naiv erwarten würde:

"~" expands to the user's home directory as present in the passwd database, according to sh semantics.

Richtig, und weil der normale User per default keine Rechte zum Mounten hat, läuft dieser Prozess unter UID 0, weswegen ~ hier auf das Homedir "/root" expandiert wird... das heisst, auf den Namen des normal angemeldeten User wird das Cache-Dir von root nach /tmp gemountet, was auf die eigentliche Absicht, das User-Dir .cache via tempfs laufen zu lassen überhaupt keine Wirkung hätte . Ich glaube nicht, dass das erwünscht ist.... und es findet ja während dieses Prozesses eben kein Kontextwechsel auf den User statt, damit ~ auf das richtige Homedir expandiert werden könnte.


Nachtrag... nach weiteren 3 mal durchlesen... tja, ich weiss es nicht wirklich... das Man-Page-Zitat hat mich jetzt verunsichert ... ich würde mich allerdings da nicht drauf verlassen und lieber eindeutige Pfade verwenden. Mir fehlt jetzt jedoch die Energie, das gegenzuprüfen, ob das wirklich korrekt expandiert wird. Deswegen sag ich mal, abhaken.... vielleicht habe ich das tatsächlich falsch interpretiert. Aber ich würde diese Unsicherheit von vornherein mit Eindeutigkeit beseitigen.

[JTH]

Mir fehlt jetzt jedoch die Energie, das gegenzuprüfen, ob das wirklich korrekt expandiert wird.

Wie gesagt, ich habs ’n paar mal ausprobiert: ~ expandiert in der pam_mount.conf.xml zum Home des Benutzers, der gerade angemeldet wird; das Mounten selbst läuft zwangsläufig, wie du schreibst, mit notwendigen „höheren“ Berechtigungen.

~ anstatt von /home/user/xyz in der pam_mount.conf.xml hat auch den Vorteil, dass das pam_mount auch für root funktioniert – der hat ja kein Home unter /home/root. ~ expandiert dann korrekt zu /root.