Habe ein Perl-CGI Script geschrieben, welches unter Anderem auf die /etc/shadow (Debian GNU/Linux) zugreift. Lokal, also als root angemeldet funzt die Sache, doch wenn ich das Script über den Apache 1.3 mit SuExec und Perl v5.8.4 laufen lasse (user: www-data (Apache), group: www-data), erahlte ich einen Internen Server Fehler, genauer gesagt:
'Cannot do setuid (cannot exec sperl)' aus der apache error.log

Die Dateiberechtigungen sind wie folgt gesetzt:

-rwsr-xr-x (u: root g: root) script.pl

Ein CGI, geschrieben in C++, läuft mit identischen Dateiberechtigungattributen problemlos (welches auch auf die /etc/shadow zugreift und dem user/gruppe root gehört).

Wie kann ich also das Script mit su-Privilegien ausführen, und zwar nur Dieses, ohne gleich der ganzen virtuellen Domäne jene Rechte geben zu müssen?

als welcher user laeuft das script? wenn es wwwrun ist, dann teste mal als root:

und du erfaehrst vielleicht mehr

läuft als www-data, doch da setuid = root sollte es egal sein

Oder trage www-data als in /etc/sudoers für dieses Skript ein.

Der wohl dem webserver am liebsten Weg wird denk ich mal suExec sein!

Wie bereits erklärt, läuft das Script per Apache-suEXEC und gehört user/gruppe root, sodass durch suEXEC das Script mit den Rechten des Scripts gestartet wird und nicht mit denen des Apache-HTTP-Servers. Zusätzlich habe ich auch versucht das suid-Bit zu setzen (oben gezeigt), doch das hat ebenfalls nicht geholfen.

???

Unter Linux hat das setzen des SUID-Bits bei einem Skript auch keinerlei Funktion...

Genau das ist ja mein Dilemma: SUID-Bit fürs Perl-Script funzt net, doch wenn das Script einem SU gehört und ich Apache mit SuEXEC laufen hab, dann müsste das Script mit den Rechten des Scriptbesitzers ausgeführt werden. Doch leider, leider lässt es suEXEC nicht zu ein CGI mit su-Rechten zu starten.

Wie kann ich also ein CGI mit su-Rechten zum Laufen kriegen, und trotzdem suEXEC einsetzen?

Vielen Dank für die Hilfe, doch ich habe die Lösung:

1. Möglichkeit:
Kernel mit suid-Bit Fkt für Scripte backen

2. Möglichkeit:
nicht /usr/bin/perl, sondern /usr/bin/suidperl verwenden (Perl-suid)

letztere Möglichkeit habe ich verwendet und es funzt prächtig

mfg