usermod schlägt fehl, wenn User ID in Prozessliste sichtbar

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von mattula, 8. Mai 2013.

  1. mattula

    mattula Member

    Hi Till,

    bin heute über folgendes gestolpert:

    Ein Kunde wollte viele seiner Shell User von Chrooted auf None ändern.
    dafür muss der minütliche ISPConfig Cron Job ein "usermod" ausführen.

    Dieses usermod schlägt fehl, wenn der User eingeloggt ist und/oder eine Prozess mit seiner UID läuft. Siehe auch "man usermod".

    Ist ja prinzipiell OK, aber jetzt existieren ständig php cgi Prozesse mit der UID des web Users (webXX), die die selbe ist, wie die des Shell Users (username). Somit findet die Änderung des Shell Users nicht statt.
    Was irgendwie doof ist, da der webXX User in dem Fall keine Interferenz mit dem Home des zu ändernden Shell Users hat.

    Das ist das Eine.

    Das Andere ist, kann es sein, dass das usermod nur einmalig ausgeführt wird, egal ob fehlerhaft oder nicht?

    Ich würde behaupten, die User werden nie geändert, wen der usermod einmalig fehl schlug. Aber im Webinterface wird die Änderung fälschlicherweise angezeigt.

    Nur ein Resync Shell USer als admin triggert den usermod wieder.

    Im o.g. Fall habe ich im End (holzhammer-mässig) kurz bevor der Cron Job anläuft ein Apache Restart ausgelöst, damit wenigstens für ein paar Sekunden die PHP CGI Prozesse der betroffenen User weg sind.

    Aber das kanns doch nicht wirklich sein, zumal das auch ein paar Anläufe gebraucht hat, bis das Dutzend Shell User mal geändert war.


    Grüße,
    Matthias
     
  2. derhord

    derhord New Member

    Hilfreich wären, Auszüge aus den Logfiles oder mal Fehlermeldungen (sofern welche angezeigt werden )?!
     
  3. mattula

    mattula Member

    Sorry, ich dachte, wer sich mit ISPConfig auskennt, weiss was ich meine, hier der Log Eintrag:

    /var/log/ispconfig/cron.log
    Code:
    usermod: user bla_bla_username is currently logged in
    
    Und wenn ich dann mit
    Code:
    ps aux | grep bla_bla_username 
    
    schaue, sehe ich keinen Prozess und der User ist auch nicht eingeloggt.

    Wenn ich aber schaue, welche uid der User hat, sagen wir in dem Fall die 1012, dann finde ich in der /etc/passwd zur uid 1012 auch einen Benutzer web14 (zusätzlich zum bla_bla_username).

    Ok, dann gucke ich wieder Prozessliste:
    Code:
    ps aux | grep web14
    
    und sehe unter anderem:

    Code:
    web14    16257  0.3  0.6 258212 50676 ?        S    18:54   0:01 /usr/bin/php-cgi -d open_basedir=/var/www/clients/client1/web14/web:/var/www/clients/client1/web14/tmp:/var/www/foo.bar/web:/usr/share/php5:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin -d upload_tmp_dir=/var/www/clients/client1/web14/tmp -d session.save_path=/var/www/clients/client1/web14/tmp
    ... und das ist das Problem. Der Shell User ist nicht eingeloggt, aber sein Web User hat dieselbe uid (was ja auch so gewollt ist).

    Und bei einer stark frequentierten Website gibt es dann halt auch die passenden Prozesse.

    Und usermod ist leider nicht so schlau, das auseinanderzudödeln.

    Und "man usermod" erklärt das Verhalten auch sehr schön:
    Matthias
     
  4. Till

    Till Administrator

    Das ist ein bekanntes problem mit usermod, leider hat der befehl keinen force parameter, daher haben wird es in 3.0.5.2 bereits fast überall durch eigenn ode ersetzt, denn linux bitet keinen passenden befehl der änderungen erzwingen kann. Wenn du bereits 3.0.5.2 einsetzt dann poste es noch,al im bugtracker, damit ich msl schaue wo noch überall usermod verwendet wird.
     

Diese Seite empfehlen