~ expandiert zum falschen Verzeichnis

  • Es geht um das Shellscript welches vom Sysinfoplugin aufgerufen wird.


    Im Script habe ich testweise das
    --
    logger echo ~
    --


    Ruft das Sysinfo Plugin das Script auf (der VDR läuft unter dem Benutzer VDR) dann kommt im Syslog das
    --
    logger: echo /root
    --


    Rufe ich das von der Shell aus auf (als Nutzer VDR eingeloggt) erhalt eich das im Syslog
    --
    root: echo /home/vdr
    --


    Das Script liegt unter /usr/local/sbin
    --
    -rw-r-xr-x 1 root staff 547 26. Apr 17:04 vdr-systeminfo
    --


    Hat da jemand ne Erklärung für? Ist da irgendein Dateiatribut (Sticky Bit?) im Spiel was das Script immer als Root ausführt? Oder wie kann ich mir dieses Verhalten erklären?
    Egal wie, VDR und Shell sollten doch das selbe Ergebnis erhalten, oder?


    cu

  • Mal ein Gedanke:


    Wird das "echo" mit ausgegeben? Dann bedeutet das lediglich, dass das "~" von dem Prozess logger interpretiert wird und nicht von der Shell, die das Skript aufruft. Ich tippe mal auf ein Quoting-Problem. Wie das aber genau zu lösen ist, weiß ich leider nicht. Eventuell mit Backticks?


    Gruß,
    Saxman2k

    Hardware: Gigabyte GA-970A-D3, AMD Athlon II X2 235e, 4GB RAM, Zotac GeForce 210 Synergy Edition 1GB, Corsair Force3 60GB SSD, Mystique SaTiX-S2 Dual, 6.4" TFT, Atric IR Einschalter Rev.5, Logitech Harmony 900, Samsung LE46A789 full HD LCD, Denon AVR-1910, USB Atmo-Light von Slime
    Software: yaVDR 0.5
    Streaming Client 1: Hauppauge MediaMVP
    Streaming Client 2: Telegant TG100 (wenn ich mal irgendwann die Zeit finde das UPnP-Plugin zu testen)

  • Die Bash-Manpage sagt dazu:

    Zitat

    If this login name is the null string, the tilde is replaced with the value of the shell parameter HOME. If HOME is unset, the home directory of the user executing the shell is substituted instead.

    Du könntest mal schauen was in $HOME des Environments des VDR-Users steht und diese ggf. setzen.
    Ansonsten empfiehlt es sich, in Shellscripten immer absolute Pfade zu verwenden um genau diesem Problem aus dem Weg zu gehen.

  • Mal ein Gedanke:


    Wird das "echo" mit ausgegeben? Dann bedeutet das lediglich, dass das "~" von dem Prozess logger interpretiert wird und nicht von der Shell, die das Skript aufruft. Ich tippe mal auf ein Quoting-Problem. Wie das aber genau zu lösen ist, weiß ich leider nicht. Eventuell mit Backticks?


    Gruß,
    Saxman2k


    Das mit dem echo stimmt (ist da eigentlich blödsinn) aber ~ wird ja expandiert wie man sieht. Es wird nur nach /root expandiert obwohl der VDR unter dem Nutzer VDR läuft.


    Die Bash-Manpage sagt dazu:

    Du könntest mal schauen was in $HOME des Environments des VDR-Users steht und diese ggf. setzen.


    echo $HOME gibt das richtige Verzeichnis aus. Nur wenn der VDR das Script aufruft klappt das nicht. Im VDR Log steht aber "switched to user 'vdr' "



    Ansonsten empfiehlt es sich, in Shellscripten immer absolute Pfade zu verwenden um genau diesem Problem aus dem Weg zu gehen.


    Naja, das Script soll ja unabhängig von sowas funktionieren. Wenn ich testweise (einfach um mal rumzuspielen zu können ohne meine Config zu vermurkzen) in der /etc/default/vdr den VDR Nutzer ändere es soll dessen Homeverzeichnis genommen werden ohne das ich alle Shellscripte ändere.


    cu

  • Naja, das Script soll ja unabhängig von sowas funktionieren. Wenn ich testweise (einfach um mal rumzuspielen zu können ohne meine Config zu vermurkzen) in der /etc/default/vdr den VDR Nutzer ändere es soll dessen Homeverzeichnis genommen werden ohne das ich alle Shellscripte ändere.


    Dann musst Du dafür sorgen, dass $HOME für den vdr-Prozess korrekt gesetzt wird. Das Environment ist immer lokal für jeden Prozess. Wenn Du ein Programm aus der Shell startest, vererbt die Shell üblicherweise das ENV an diesen Prozess. Daher funktioniert der Test, wenn Du Dich als User 'vdr' einloggst. Der vdr-Prozess wird aber von irgendeinem Init-Script gestartet, das möglicherweise ein völlig anderes Environment hat.
    Du könntest versuchen, $HOME in diesem vdr-startscript zu setzen, das sollte helfen.


  • Dann musst Du dafür sorgen, dass $HOME für den vdr-Prozess korrekt gesetzt wird. Das Environment ist immer lokal für jeden Prozess. Wenn Du ein Programm aus der Shell startest, vererbt die Shell üblicherweise das ENV an diesen Prozess. Daher funktioniert der Test, wenn Du Dich als User 'vdr' einloggst. Der vdr-Prozess wird aber von irgendeinem Init-Script gestartet, das möglicherweise ein völlig anderes Environment hat.
    Du könntest versuchen, $HOME in diesem vdr-startscript zu setzen, das sollte helfen.


    Das heisst wenn der VDR als User VDR läuft dann bedeutet es nicht automatisch das er das Enviroment des Users hat? Hm, jetzt wo du es sagst scheint das Verhalten dann logisch zu sein.


    Wozu ist dann der Kommandozeilenparamter --user gut? Dann nimmt man doch besser su vdr -c um den VDR als User zu starten. Oder entgeht mir hier jetzt was?



    Ich setze jetzt im VDR Startscript
    --
    export VDR_HOME=$(su $VDROPT_USER -c "echo ~")
    --


    Und nutze im Script dann $VDR_HOME (anstelle von ~).


    Damit komme ich dann gut hin. Danke, da war ich irgendwie komplett auf der falschen Spur.


    cu

  • Zitat

    Das heisst wenn der VDR als User VDR läuft dann bedeutet es nicht automatisch das er das Enviroment des Users hat? Hm, jetzt wo du es sagst scheint das Verhalten dann logisch zu sein.

    Genau. Der vdr-Prozess wird als root (von init) gestartet und "droppt" dann die Rechte. Damit erbt er das Environment des init-scriptes.


    Zitat

    Wozu ist dann der Kommandozeilenparamter --user gut? Dann nimmt man doch besser su vdr -c um den VDR als User zu starten. Oder entgeht mir hier jetzt was?

    Prozesse unter einem limitierten Useraccount laufen zu lassen hat in erster Linie Sicherheitsgründe. Damit hat ein Exploit nicht automatisch root-Rechte. Deutlich wird das z.B. bei Apache: Der startet als root um sich an Port 80 binden zu können, droppt aber dann die Rootrechte und läuft als www-data. Sollte sich jetzt ein Pöser Pube nun den Apachen exploiten, hat er als www-data nur eingeschränkte Möglichkeiten Unsinn zu machen.

  • Prozesse unter einem limitierten Useraccount laufen zu lassen hat in erster Linie Sicherheitsgründe. Damit hat ein Exploit nicht automatisch root-Rechte. Deutlich wird das z.B. bei Apache: Der startet als root um sich an Port 80 binden zu können, droppt aber dann die Rootrechte und läuft als www-data. Sollte sich jetzt ein Pöser Pube nun den Apachen exploiten, hat er als www-data nur eingeschränkte Möglichkeiten Unsinn zu machen.


    Jup, so wollte ich das ja eigentlich auch.


    Aber irgendwie scheint mir die Methode mit dem VDR Kommandozeilenparamerter --user ungünstig. Bin jetzt gerade eben nämlich schon wieder darauf reingefallen ;) Weil freevo per externalplayer Plugin gestartet trifft auf das selbe Problem mit dem falschen Enviroment. Aber diesmal habe ich mich nur kurz gewundert ;)


    Ich starte den VDR jetzt per SU <username> und vergesse das mit dem --user Kommandozeilenparameter einfach mal.


    cu

  • Code
    man env


    Code
    env HOME=/home/vdr vdr ...


    Soll heißen: Passender "env"-Befehl dem VDR-Aufruf vorangestellt und die HOME-Variable wird genau für diesen Prozess richtiggestellt. Das ist auch deshalb wichtig, da man unter Umständen Programme über commands.conf aufrufen möchte, die auch ein korrektes HOME voraussetzen.


    Großer Vorteil: Dieses "env HOME=/home/vdr" kann man in der runvdr-extreme als "Wrapper" festlegen.

  • Ja aber, ist HOME denn wirklich das einzige was die verschiedenen Enviroments unterscheidet?


    cu

  • Aber irgendwie scheint mir die Methode mit dem VDR Kommandozeilenparamerter --user ungünstig.
    [..]
    Ich starte den VDR jetzt per SU <username> und vergesse das mit dem --user Kommandozeilenparameter einfach mal.


    Der Vorteil, wenn VDR selbst den User-Switch durchführt, ist die Möglichkeit, einige root-Rechte dabei mit herüber zu retten. Genauer gesagt, bewahrt sich VDR zwei root-Rechte: Das Recht, die System-Uhr zu stellen, und das Recht, einen Thread in der Priorität anzuheben (höher als normale Priorität). Beides darf der User vdr eigentlich nicht.


    Gruß,


    Udo

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!