Script soll unter anderer UID ausgeführt werden

Hans-Dietrich Kirmse hd.kirmse at gmx.de
Mo Jan 11 19:43:46 CET 2010


Hallo Mario,

Mario Lorenz schrieb:
> Am 10. Jan 2010, um 19:21:16 schrieb Frank Loeffler:
>> Hi,
>>
>> On Sun, Jan 10, 2010 at 10:55:15PM +0100, Hans-Dietrich Kirmse wrote:
>>> Bin an weiteren Ideen interessiert.
>> Sudo hat dafuer eine Option:
>>
>>        -S  The -S (stdin) option causes sudo to read the password from
>> the standard input instead of the terminal device.
> 
> Moin,
> In allen o.g. Fällen muss das Passwort so abgespeichert sein, 

die Situation ist etwas anders. Vielleicht erinnerst du dich an den
Thread mit den 2 Apache-Instanzen. Diese Lösung wird nicht umgesetzt.

Es geht um Folgendes: es gibt derzeit ca. 20 Scripte zur Verwaltung von
Usern, Gruppen und Hosts (im LDAP). Diese sind in Perl geschrieben und
wurden bisher immer als root aufgerufen.

Um diese Scripte für Lehrer leicht zu händeln, wird (von einem anderen
Lehrer) ein Webinterface in PHP erstellt. An diesem Webinterface muss
man sich als Lehrer natürlich anmelden (d.h. es liegen das Login und
Passwort vor) und dann wird durch ein PHP-Script eben eines dieser
Perlscripte aufgerufen. Das Passwort muss (eigentlich) nicht
abgespeichert werden, sondern "nur" weitergereicht werden.
Es gibt damit überhaupt kein Problem, einen sudo-Aufruf abzusetzen, wo
neben dem Pfad zum Script auch das Login und Passwort des aufrufenden
Lehrers angegeben wird.

> dass www-data
> das lesen kann. Damit kann ein beliebiges www-data CGI-Script das auch lesen,
> und vollständig "teacher" werden.
> Drum nimm lieber sudo, und trag in /etc/sudoers ein:
> (ausm hut, ich hoff das is so korrekt)
> 
> www-data ALL = (teacher) NOPASSWD: /home/scripts/dosomething.sh

allerdings ist es mir beim Schreiben dieser Mail deutlich geworden, das
es in Hinsicht Sicherheit keinerlei Nachteil bringt, wenn in der sudoers
NOPASSWD: genutzt wird. Es geht ja darum, dass die Scripte unter einer
anderen UID laufen und das wird ja erreicht.

die Sicherheit der Scripte werden wir nun dadurch erreichen, dass die
Perl-Scripte zusätzlich das Login und das Passwort als Paramter
übernehmen und sich ebenfalls am LDAP authentifizieren und autorisieren.
Und was noch wichtiger ist, auch das Binden an den LDAP wird mit dem DN
des Users gemacht und nicht mehr mit dem LDAP-root-Account.

> und ruf im Script auf: sudo -u teacher /home/scripts/dosomething.sh

ja so sollte das reichen. Trotzdem klappt es auch so nicht, weil PAM
trotzdem korrekt konfiguriert sein muss, was aber leider nicht der Fall ist.

Aber ich denke, wir wissen jetzt, wie wir weiter machen müssen.

Danke auch für deine Antwort.

Mit freundlichen Grüßen
Hans-Dietrich