Habe hier einen Systemd Service den ich nicht zur Mitarbeit bewegen kann

[Unit]
Description=Guestsession Service
After=systemd-user-sessions.service getty@tty${SDDM_INITIAL_VT}.service plymouth-quit.service systemd-logind.service

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStop=/usr/sbin/rm -rf /home/guest/.*
ExecStop=/usr/sbin/rm -rf /home/guest/*
ExecStop=/usr/sbin/bash -c 'cp -a /etc/skel/. /home/guest'
ExecStop=/usr/sbin/chown -R guest:users /home/guest

[Install]
WantedBy=multi-user.target
#WantedBy=sysinit.target

Status

systemctl status guest-session.service
● guest-session.service - Guestsession Service
Loaded: loaded (/etc/systemd/system/guest-session.service; enabled; preset: disabled)
Active: active (exited) since Sat 2024-05-11 13:10:42 CEST; 8min ago

Mai 11 13:10:42 intel-i7 systemd[1]: Finished Guestsession Service. 

Laufen tut er anscheinend, aber er leert mir nicht das Guesthome. Im log finde ich auch nur Finished Guestsession Service, keine Fehlermeldung das er was nicht kann, warum arbeitet er nicht?

  • brikler hat auf diesen Beitrag geantwortet.

    Wie wäre es mit diesem Befehl userdel -r guest
    Und dann denke ich mal, dass das After= hier wahrscheinlich nie eintritt.

    • Martin-MS hat auf diesen Beitrag geantwortet.

      tuxnix Und dann denke ich mal, dass das After= hier wahrscheinlich nie eintritt.

      Muss auch nicht zwingend.

      After= besagt lediglich, dass wenn sich eine der angegebenen units im Startprozess befindet dann bei gleichzeitigem Start so lange gewartet werden soll, bis sie den active-Status erreicht hat. Wenn die unit schon active ist, dann läuft die Verarbeitung weiter. Wenn sie inactive ist, wird sie nicht gestartet und folglich auch nicht darauf gewartet, sondern die Verarbeitung läuft dann weiter.

      Das dürfte also nicht den Start verhindern, und wie man sieht, startet sie ja auch, es passiert nur nichts, was meiner Meinung an der falschen Verwendung von ExecStop= liegt.

      Die Verwendung von RemainAfterExit= halte ich hier auch für kontraproduktiv, weil die unit obwohl keine Verarbeitung mehr stattfindet trotzdem noch den Status active behält. Es mag sicherlich Anwendungsfälle geben, in denen das sinnvoll ist, hier sehe ich das aber nicht.

      @tuxnix ich möchte das Verzeichnis leeren und nicht den User löschen

      Das After= hab ich aus dem sddm.service.
      Ich möchte gerne den Service nach dem ausloggen von Guest laufen lassen oder zumindest nach dem ausloggen, deswegen RemainAfterExit=yes, hab es jetzt durch Restart=always, auch aus dem sddm.service, ersetzt. Brachte beides leider keinen Erfolg.

      Nicht sicher bin ich mir bei dem Install ob da multi-user.target richtig ist?

      Es spielt auch keine Rolle ob ich ExecStart= , ExecStop= oder beides mache es funktioniert nicht.

      • tuxnix hat auf diesen Beitrag geantwortet.

        @Martin-MS

        Wenn sie inactive ist, wird sie nicht gestartet und folglich auch nicht darauf gewartet, sondern die Verarbeitung läuft dann weiter.

        Verstehe ich nicht. Welchen Sinn würde es denn dann überhaupt machen ein After="service der inaktiv ist und es auch bleibt" zu setzen.

        M.M.n. ist das After= dafür da, mit der Ausführung so lange zu warten bis ein activ-status bzw. ein target erreicht wurde. Oben wartet After= aber auf ein Ereignis, dass in der Vergangenheit liegt bzw. etwas das keinen Status mehr melden kann weil es beendet wurde.

        • Martin-MS hat auf diesen Beitrag geantwortet.

          tuxnix Verstehe ich nicht. Welchen Sinn würde es denn dann überhaupt machen ein After="service der inactiv ist und es auch bleibt" zu setzen.

          Die Frage müsste eher lauten, welchen Sinn es macht, in dem After=-Array eine Unit zu setzen, die nie aktiviert würde.
          Der Nutzen ist einfach der, dass auf die dort aufgeführten Units gewartet wird, wenn sie durch den eigenen (mit Requires= angeforderten) oder einem anderen Prozess gestartet wurden, bis sie aktiv sind. Andernfalls könnte es zu Laufzeitfehlern kommen, wenn schon auf Funktionen der gestarteten Unit zugegriffen wird, bevor sie aktiv ist.

          • tuxnix hat auf diesen Beitrag geantwortet.

            Andy@Arch
            Mir ist gar nicht so klar was du mit dem Service überhaupt bewirken möchtest.

            • Andy@Arch hat auf diesen Beitrag geantwortet.

              tuxnix dächte das erklärt sich von selber, ich möchte einen (Guest)User mit Gedächtnisschwund haben, das hier hat mich drauf gebracht, das funktioniert aber auch nicht so wie ich es gerne möchte.

              Edit:
              50% hab ich geschaftt, so funktioniert der Service zumindest nach dem booten

              [Unit]
              Description=Guestsession Service
              After=systemd-user-sessions.service systemd-logind.service
              
              [Service]
              Type=oneshot
              
              ExecCondition=  /usr/sbin/sh -c 'rm -rf /home/guest'
              ExecCondition=  /usr/sbin/sh -c 'mkdir /home/guest'
              ExecCondition=  /usr/sbin/sh -c 'cp -a /etc/skel/. /home/guest'
              ExecStart=      /usr/sbin/sh -c 'chown -R guest:users /home/guest'
              
              [Install]
              WantedBy=multi-user.target

              Leider nur nach dem booten, nicht nach dem sich der User aus geloggt hat.

              //Edit:

              Ein script wie z.B. guest.sh im Ordner /etc/profile.d/ wird bei jedem Login ausgeführt. Das klappt sogar auch mit Loginmanager und braucht keinen zusätzlichen systemd-service.

              /etc/profile.d/guest.sh

              #!/bin/bash
              
              #  UID von user guest ist bei mir 1002
              
              if [ $EUID -eq 1002 ] ; then
              	rm -rf /home/guest/*
              fi
              • Andy@Arch hat auf diesen Beitrag geantwortet.

                tuxnix die Idee ist nicht schlecht, nur hätte ich das ganze gerne beim Logout. Was mir da einfällt ist trap, nur welches Signal nimmt man?

                • tuxnix hat auf diesen Beitrag geantwortet.

                  Der Service sieht gut aus.
                  Meine Frage wäre, ob dieser auch korrekt als User Service für den Benutzer guest installiert wurde.
                  Da er in /etc/systemd/system anstatt in /etc/systemd/user liegt, nehme ich mal an, dass dies nicht der Fall ist.
                  Eine Alternative zur Lösung des zugrundeliegenden Problems wäre systemd-homed mit einem tmpfs für den User.

                    schard Eine Alternative zur Lösung des zugrundeliegenden Problems wäre systemd-homed mit einem tmpfs für den User.

                    Genau dafür ist das doch da, oder hab ich das falsch verstanden?

                    Einen solchen systemd-Service im Usercontext laufen zu lassen ist ein "Sicherheitsrisiko", da der User den Service ja einfach beenden könnte.

                    schard Meine Frage wäre, ob dieser auch korrekt als User Service für den Benutzer guest installiert wurde.

                    Wie sollte das denn deiner Meinung nach installiert werden?

                    • Dirk hat auf diesen Beitrag geantwortet.

                      Was mir gerade noch einfällt: was auch eine Möglichkeit wäre, aber schon ein bisschen böse, wäre für /home/guest ein tmpfs zu benutzen, damit wären ohne weiteres zwar nur nach einem Neustart alle Daten unwiederbringlich weg, aber eben komplett ohne dass man das Verzeichnis selbst jedes Mal anfassen müsste.

                      Andy@Arch Wie sollte [der User-Service] denn deiner Meinung nach installiert werden?

                      Na ja, du kannst systemd-Services ja auch im Usercontext starten. Zum Beispiel um Timer zu benutzen und nicht jedes mal erst als root was zu konfigurieren. Die Units laufen dann eben im Usercontext und haben auch das Environment des Users griffbereit, ohne groß irgendwas Konfigurieren zu müssen.

                      Aber hier würde das nur bei "ehrlichen" Anwendern funktionieren, jemand mit "böser Absicht" könnte den Service im Usercontext halt einfach beenden und das hier diskutierte Setup damit zu einem gewissen Maße aushebeln.

                      Andy@Arch nur hätte ich das ganze gerne beim Logout.

                      Das bleibt sich im Ergebnis gleich.
                      Ob ein Zimmer (Guestaccount) beim Einchecken oder beim Auschecken gereinigt wird kann dem Gast egal sein. Er betritt immer ein sauberes Zimmer. Was die Sicherheit und die Privatsphäre betrifft, so ist das auch einerlei, weil hier der Gast ohnehin darauf angewiesen ist, dem Wirt (Admin) zu vertrauen.

                      Was mir da einfällt ist trap

                      Trap wird nicht klappen wenn die Sitzung von einem Loginmanager und nicht von einem Skript aus gestartet wird.

                      Um bei der Analogie zu bleiben: Es wäre sinnvoller das Zimmer zu reinigen bevor ein Gast kommt. Ansonsten guckt der erste in die Röhre. Das mag ein Edge Case sein, ist aber eine Überlegung wert.

                      Aus Datenschutzsicht ist es zudem sinnvoll, übergebliebene Daten nach Ende der Sitzung zu löschen. Ein tmpfs erfüllt beide Anforderungen.

                      Eine weitere Frage betreffend den Use Case des Themenerstellers für mich wäre, welches Verhalten erwartet wird, wenn sich GastA mit dem Benutzerkonto gast anmeldet, und sich während seiner Session ein weiterer GastB mit selbigem Benutzerkonto anmeldet.

                      Das tmpfs wird doch auch beim Boot eingehangen und beim shutdown ausgehangen richtig? Oder ist es möglich das mit dem User login bzw logout zu verbinden?