Mit CGI/Perl Shell-Script aufrufen und Login simulieren

[Danny]

Hallo Welt,

über eine Web-Oberfläche möchte ich beliebige Shell-Scripte im Unix-Umfeld starten. Das funktioniert soweit auch ganz gut.

Leider brechen einige Scripte mit Fehlermeldungen ab (Rechte-Problem), die über eine Terminal-Emu (WinXP-Client <> Netzwerk <> Unix-Maschine) einwandfrei funktionieren.

Das Problem: Erforderlich ist User XY, der Webserver startet die Shell aber automatisch immer mit "apache", der wohl in der http.conf eingetragen ist. Ich finde einfach keine Möglichkeit diesen User-Namen dynamisch zu wechseln, z.B. durch HTTP-Auth. Die Unix-Befehle login und su funktionieren scheinbar nicht ohne Terminal, die Einspeisung des Passwortes durch Umleitung klappt jedenfalls nicht. :(

In Perl kann man System-Kommandos, bzw. Scripte mit Parametern ausführen und anschließend deren Ausgabe abholen aber nicht interaktiv eingreifen...

Was tun?

freundlichen Gruß
Danny

[Philipp Hasenfratz]

Halihallo Danny

Leider brechen einige Scripte mit Fehlermeldungen ab (Rechte-Problem), die über eine Terminal-Emu (WinXP-Client <> Netzwerk <> Unix-Maschine) einwandfrei funktionieren.

Nun, die Scripte laufen unter dem User, unter dem Apache läuft. Laut
deiner Aussage ist das der User "apache".

Das Problem: Erforderlich ist User XY, der Webserver startet die Shell aber automatisch immer mit "apache", der wohl in der http.conf eingetragen ist.

Richtig.

Ich finde einfach keine Möglichkeit diesen User-Namen dynamisch zu wechseln, z.B. durch HTTP-Auth.

Nun, HTTP-Auth hat mit der Berechtigung auf dem lokalen System nichts
zu tun.

Die Unix-Befehle login und su funktionieren scheinbar nicht ohne Terminal, die Einspeisung des Passwortes durch Umleitung klappt jedenfalls nicht. :(

Bei login:
Philipp:~# man login

login  is used to establish a new session with the system.
       It is normally invoked automatically by responding to  the
       login:  prompt  on the user's terminal.  login may be spe­
       cial to the shell and may not be invoked as a sub-process.

login darf nicht als sub-prozess gestartet werden => keine
Möglichkeit login in einem von Apache gestarteten Prozess zu starten.

Bei su:
Philipp:~# man su

su  is used to become another user during a login session.
       Invoked without a username, su defaults  to  becoming  the
       super  user.

Hm. "during a login session". Das ist ein Apache Sub-Prozess
natürlich nicht...

Das sind nur Passagen aus der Doku, die mir aufgefallen sind. Ich
habe damit jedoch keine Erfahrung und weiss eigentlich nicht genau
wovon ich rede :-)

Es gäbe da noch etwas: setuid() im Perlprogramm selber. Lies hierzu
einmal 'man setuid'. Aber sei bei derartigen Angelegenheiten sorgsam
und vorsichtig, denn damit öffnest du eine empfindliche Schwachstelle
in deinem System. Nicht nur Schwachstelle, sondern ein potenziell
offener Zugriff mit root-privileges, was katastrophal ist! - Falls es
denn überhaupt ausgeführbar ist...

In Perl kann man System-Kommandos, bzw. Scripte mit Parametern ausführen und anschließend deren Ausgabe abholen aber nicht interaktiv eingreifen...

Doch. Inter Process Communication als Stichwort:

perldoc IPC::Open2
perldoc IPC::Open3
perldoc perlipc

oder open mit je einer Pipe für Input und Output (IPC::Open2).

Viele Grüsse

Philipp

[Danny]

Hi Philipp,

danke für die Hinweise! Auf der Apache-Website habe ich inzwischen etwas über User und Gruppen für bestimmte URLs gefunden, in Verbindung mit virtual hosts. Damit müßte es funktionieren.

MfG
Danny

[Philipp Hasenfratz]

Halihallo Danny

danke für die Hinweise! Auf der Apache-Website habe ich inzwischen etwas über User und Gruppen für bestimmte URLs gefunden, in Verbindung mit virtual hosts. Damit müßte es funktionieren.

Oha... Eine gutgemeinte Warnung:
Spiel nie mit Usern und Permissions rum, wenn du sie nicht verstehst.
Wie bereits gesagt: Das öffnet potenzielle und schwerwiegende
Sicherheitslücken! - !Besonders! wenn du Apache unter root laufen
lässt, bzw. einige Scripte unter root-Permissions ausführst!

Du darfst deine nächsten Schritte natürlich selber entscheiden, das
nehme ich dir nicht ab. Aber meine Empfehlung ist, dass du dich erst
gründlichst mit Unix-Berechtigungen und Sicherheit befasst, bevor du
die nächsten Schritte beginnst.

Viele Grüsse

Philipp

[Danny]

Ist schon klar, ich habe mir auch bereits zuvor Gedanken über Security und so weiter gemacht. Das Script läuft im Intranet, damit ist die potenzielle Gefahr schon mal geringer als bei einer öffentlichen Webseite (das hoffe ich jedenfalls ;-)

Root-Permissions brauche ich nicht, nur den User, der die Scripte erstellt hat und als einziger ohne Einschränkungen laufen lassen darf (DB-Zugriff nur von diesem speziellen User möglich). Außerdem werde ich über virtueal Hosts sicherstellen, dass nur ein bestimmtes Verzeichnis diesen User incl. Gruppe bekommt, welches ich zusätzlich mit .htaccess, bzw .htusers schütze. Das müßte eigentlich sicher genug sein...