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

[mattula]

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

 

[derhord]

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

 

[mattula]

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

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

/var/log/ispconfig/cron.log

usermod: user bla_bla_username is currently logged in

Und wenn ich dann mit

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:

ps aux | grep web14

und sehe unter anderem:

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:

CAVEATS
You must make certain that the named user is not executing any processes when this command is being executed if the user's numerical user ID, the user's name, or the user's home directory is being changed. usermod checks this on Linux, but only check if the user is logged in according to utmp on other architectures.

Matthias

 

[Till]

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.