Re: Suexec testen

[Ekkehard Rummel]

Jochen Kächelin <[EMAIL PROTECTED]> writes:

> Wie kann ich denn testen, ob mein suexec richtig konfiguriert ist!
> Eigentlich  soll  suexec  ja  verhindern,  dass kunde a perl-scripte
> unter  der Kennung des Kunden b alaufen lassen kann, um somit keinen
> Schaden anzurichten, gelle?

Ich habe mir dafür ein kleines Shell-Script geschrieben:

,
| #!/bin/sh
| 
| echo -e "Content-Type: text/plain\n\n"
| 
| echo -n "User: "; whoami
| echo -n "Group(s): "; groups
| echo
| echo "Environment:"; env
`

-- 
Aus rechtlichen Gruenden ist es zur Zeit leider nicht moeglich, an dieser
Stelle eine Signatur anzubieten. Vielen Dank fuer Ihr Verstaendnis.


--
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)

Re: Suexec testen

[Heiko Schlittermann]

On Sun, Sep 01, 2002 at 05:55:46PM +0200, Jochen Kächelin wrote:
> Wie kann ich denn testen, ob mein suexec richtig konfiguriert ist!
> Eigentlich  soll  suexec  ja  verhindern,  dass kunde a perl-scripte
> unter  der Kennung des Kunden b alaufen lassen kann, um somit keinen
> Schaden anzurichten, gelle?

Eher so, daß Scripte des Kunden B unter der Kennung von B ablaufen.
Ein kleiner Testscript:

#! /bin/sh
# (c) 2002 Heiko Schlittermann <[EMAIL PROTECTED]>
#
# Diesen Script einfach installieren als test.cgi
# oder cgi-bin/test oder cgi-bin/test.sh, je nach dem, was der 
# jeweilige Provider gerne sehen wuerde ...
# Und dann aufrufen: 
#   http://www.irgendwo.de/test.cgi
# oder entsprechend des Installationsortes
#   http://www.irgendwo.de/cgi-bin/test
#

PERL_MODULES="CGI CGI::Carp Mail::Mailer DBI DBD::mysql \
Date::Calc Digest::MD5"

PROGRAMS="perl sendmail date env php php3 php4 ls"
PATH="/usr/bin:$PATH:/usr/sbin"
TOP="[ top ]"

cat <
CGI-Test


[ Environment ] 
[ perl ] 
[ perl modules ] 
Welcome from $REMOTE_ADDR

UID$(id -un)
GID$(id -gn)
Current Directory$(pwd)
xxx

for prog in $PROGRAMS; do
echo "$prog`type -p $prog`"
done

cat <

$TOP Environment

`export|sort|sed 's/declare -x //'|sed 's,=,,;s,^,,;s,$,,'`



$TOP Perl


`perl -V`


$TOP Perl Modules

xxx

#echo 'ModulVersion'
echo ''
for module in $PERL_MODULES; do
echo "$module" 
perl -M$module -e "print \"\$$module::VERSION\n\";" || echo "NONE"
echo ""
done
echo ''

echo ""



-- 
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)

Re: Suexec testen

[Ivo Schwalbe]

Du schriebst am Sonntag, den 01. September 2002:

> Wie kann ich denn testen, ob mein suexec richtig konfiguriert ist!
> Eigentlich  soll  suexec  ja  verhindern,  dass kunde a perl-scripte
> unter  der Kennung des Kunden b alaufen lassen kann, um somit keinen
> Schaden anzurichten, gelle?

Puh, dieser Einsatzzweck ist mir neu. Ich kenne suexec als Wrapper,
der CGI-Scripte mit einer anderen Benutzerid als "User" (eingestellt
in der Apache-Konfiguration -- Default: wwwdata) ausführen kann. Ich
teste das immer, indem ich einfach ein CGI schreibe, was mir eine
Datei erstellt. Dann schaue ich, welchem Benutzer die Datei gehört und
kann somit feststellen, mit welchen Rechten das CGI läuft:

#!/usr/bin/perl -w# wie immer
system("touch testdatei.txt");# oder auch anders
print "Content-type: text/html\n\n";  # Content-type-Header ausgeben
print "Ende gut, alles gut!"; # Fürs Protokoll

Wenn das Script suexec läuft, dann hat die Datei den Owner des
Verzeichnisses, in dem das CGI läuft, wenn nicht, dann ist mit dem
suexec etwas nicht in Ordnung.

> Gibt's da vielleicht ein Testttoll oder so?

Keine Ahnung.

tschau
*iv

-- 
Nach Bertrand Russell ist eine Meinung, die weite Verbreitung findet,
angesichts der Dummheit der Mehrheit aller Menschen mit groesserer
Wahrscheinlichkeit toericht als vernuenftig. Genau dasselbe trifft
auch auf die Wahl des Betriebssystemes zu.xteddy in heise.de/tp


-- 
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)