shell_exec will nicht funktionieren

Hallo,

ich habe ein hoffentlich kleines Problem mit PHP. Und zwar wollen die folgenden Zeilen beim besten Willen funktionieren:
PHP:
$ausgabe = shell_exec('gpg --list-keys');
echo $ausgabe;

Dagegen funktioniert das schon:
PHP:
$ausgabe = shell_exec('date');
echo $ausgabe;
Ich verstehs einfach nicht.

Jemand eine Idee?

Gruß odigo
 
Mal mit exec() versuchen. Wenn das nicht hilft, dann mal den kompletten Pfad zum gpg angeben.
 
Geht leider beides nicht ?(

Edit: Habs gerade mit gpg --help probiert. Da bekomm ich die letzte Zeile der Hilfe. Kann es irgendein Problem sein wegen der mehrzeiligen Ausgabe von gpg?
 
Bekommst du den Output auch dann nicht, wenn du den Befehl in Backticks einschließt?

Code:
$ausgabe = `gpg --list-keys`;
 
Irgendwie hab ich jetzt nicht ganz verstanden was du willst. Im ersten Posting hab ich mich etwas vertan. Ich habs natürlich so:
PHP:
$ausgabe = exec("gpg --list-keys");
echo $ausgabe;
Also keien Backticks sondern Anführungszeichen.
strlen sagt übrigens auch daß in ausgabe nichts drin ist.
Nur bei --help bekomm ich die letzte Zeile der Hilfe. Versteh ich nicht.
 
Ich glaube ich steh auf der Leitung.
Also bei:
PHP:
<?php $ausgabe = exec("gpg --list-keys");
echo $ausgabe; ?>
nix
bei:
PHP:
<?php $ausgabe = exec('gpg --list-keys');
echo $ausgabe; ?>
nix
bei:
PHP:
$ausgabe = `gpg --list-keys`;
echo $ausgabe;
bekomm ich natürlich
aufn Bildschirm

Edit: Was auch merkwürdig ist das wenn ich
PHP:
$ausgabe = exec('gpg --list-keys > test');
mache bekomme ich nur eine leere Datei namens test
 
Original von odigo
bei:
PHP:
$ausgabe = `gpg --list-keys`;
echo $ausgabe;
bekomm ich natürlich
aufn Bildschirm
Das ist seltsam, denn normalerweise sollte der Output des Programms ausgegeben werden. Unter http://www.bitmuncher.de/test.php habe ich das mal mit '$ausgabe = `gpg --help`;' gemacht. Siehe dazu auch die PHP-Doku:

http://de2.php.net/manual/en/function.shell-exec.php
Description
string shell_exec ( string $cmd )

This function is identical to the backtick operator.

Original von odigo
Edit: Was auch merkwürdig ist das wenn ich
PHP:
$ausgabe = exec('gpg --list-keys > test');
mache bekomme ich nur eine leere Datei namens test

Hast du den Befehl mal auf der Konsole ausgeführt und zwar mit den Rechten des Webservers? Wenn im Home-Verzeichnis des Webserver-Users (welches das ist, kannst du der /etc/passwd entnehmen und unter welchem User der Webserver läuft, steht in der Webserver-Konfiguration) nämlich keine GPG-Keys sind, bekommst du beim ersten Aufruf etwa folgenden Output:

Code:
gpg: Verzeichnis `/var/www/.gnupg' erzeugt
gpg: Neue Konfigurationsdatei `/var/www/.gnupg/gpg.conf' erstellt
gpg: WARNUNG: Optionen in `/var/www/.gnupg/gpg.conf' sind während dieses Laufes noch nicht wirksam
gpg: Schlüsselbund `/var/www/.gnupg/pubring.gpg' erstellt
gpg: /var/www/.gnupg/trustdb.gpg: trust-db erzeugt

und beim zweiten Aufruf kommt durch das leere Schlüsselbund garkeine Ausgabe.
 
Wie bitmuncher schon sagt: schau mal, ob du mit dem Benutzer, unter dem der Webserver läuft, überhaupt die Rechte hast, um gpg auszuführen. Außerdem schau mal, ob gpg irgendwo im $PATH des jeweiligen Nutzers steht (hadder aber auch schon gesagt *g).

Zudem könnte es sein, dass der Webserver in einer chroot-Umgebung läuft und gpg somit gar nicht verfügbar ist. Eine weitere Möglichkeit wäre, dass der Safe-Mode aktiviert ist und die Funktion damit gar nicht funktioniert, wenn du aber in einigen Fällen (wenn auch unerwünschte) Ausgaben bekommst, würde ich das aber eher ausschließen.
 
Also, es ist ein Rechteproblem. Wenn ich als User des Webservers gpg ausführe bekomme ich einen Fehler daß er auf /root/.gnupg nicht zugreifen kann.
In der Userverwaltung bin ich nicht so fit, aber ich denke ich bekomm das jetzt hin.
Danke Leute

Gruß odigo
 
Der Webserver sucht seine GPG-Konfiguration im root-Home? Du solltest dringend die Sicherheit deines Servers überprüfen, denn dieser dürfte nichtmal auf die Idee kommen seine Konfigurationen im root-Home zu suchen. Oder hast du 'gpg' via 'sudo' aufgerufen? Dann sucht er nämlich automatisch am falschen Ort.
 
Ja, habs per sudo aufgerufen. das kann ja nicht gehen.

Hm, wenn ich jetzt als www (mein neuer User fürn Apache) gpg ausführe geht alles, aber aus PHP immer noch nicht. Langsam aber sicher bekomme ich graue Haare.

Gruß odigo
 
Original von odigo
Hm, wenn ich jetzt als www (mein neuer User fürn Apache) gpg ausführe geht alles, aber aus PHP immer noch nicht. Langsam aber sicher bekomme ich graue Haare.

"Geht alles"? Er zeigt dir also Keys an? Dann kann ich mir nämlich nur vorstellen, daß der Output von gpg auf STDERR ausgegeben wird anstatt auf STDOUT und ich bin mir nicht sicher, ob PHP das auch "abfängt". In diesem Fall müßtest du jeglichen Output in eine Datei umleiten und dann diese mit PHP öffnen um daraus die Ausgabe zu erhalten

PHP:
<?php $ausgabe = exec('gpg --list-keys > test 2>&1'); ?>

oder explizit nur den STDERR umleiten

PHP:
<?php $ausgabe = exec('gpg --list-keys 2> test'); ?>
 
Das mit der Umleiterei hab ich gerade gemacht. Die Datei test wo ich Fehlerausgabe hinleite ist vom User und der Group www. Ich bekomme aber immer noch den Fehler daß gpg nach /root/.gnupg zugreifen will. In meiner http.conf steht:
User www
Group www
Das stimmt doch oder?

Edit: Ich glaube langsam aber sicher daß gpg falsch installiert ist. Die gpg.conf liegt tatsächlich unter /root/.gnupg. Wie ich daß aber wieder richtig hinbiege weiß ich nicht.
 
Wie sieht denn der Eintrag für den User 'www' in /etc/passwd aus? Und läuft der Webserver in einer chroot-Umgebung?

Edit: Jeder User hat im Normalfall seine eigenen GPG-Konfiguration und seine eigenen Schlüsselbund-Dateien in ~/.gnupg.
 
Dann mach dich mal mit 'su - www' zum Webserver-User und rufe dann nochmal den gpg-Befehl auf. Wenn das nicht den oben beschriebenen Output liefert, dann schau nach, ob es das Verzeichnis /home/www/.gnupg gibt. Wenn ja, poste mal bitte den Inhalt der /home/www/.gnupg/gpg.conf.
 
Also wenn ich als www unterwegs bin funktioniert gpg bestens. Macht alles was es soll.
Die Datei existiert da, hier der Inhalt:
# Options for GnuPG
# Copyright 1998, 1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
#
# This file is free software; as a special exception the author gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.
#
# This file is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#
# Unless you specify which option file to use (with the command line
# option "--options filename"), GnuPG uses the file ~/.gnupg/gpg.conf
# by default.
#
# An options file can contain any long options which are available in
# GnuPG. If the first non white space character of a line is a '#',
# this line is ignored. Empty lines are also ignored.
#
# See the man page for a list of options.

# Uncomment the following option to get rid of the copyright notice

#no-greeting

# If you have more than 1 secret key in your keyring, you may want to
# uncomment the following option and set your preferred keyid.

#default-key 621CC013

# If you do not pass a recipient to gpg, it will ask for one. Using
# this option you can encrypt to a default key. Key validation will
# not be done in this case. The second form uses the default key as
# default recipient.

#default-recipient some-user-id
#default-recipient-self

# Use --encrypt-to to add the specified key as a recipient to all
# messages. This is useful, for example, when sending mail through a
# mail client that does not automatically encrypt mail to your key.
# In the example, this option allows you to read your local copy of
# encrypted mail that you've sent to others.

#encrypt-to some-key-id

# By default GnuPG creates version 3 signatures for data files. This
# is not strictly OpenPGP compliant but PGP 6 and most versions of PGP
# 7 require them. To disable this behavior, you may use this option
# or --openpgp.

#no-force-v3-sigs

# Because some mailers change lines starting with "From " to ">From "
# it is good to handle such lines in a special way when creating
# cleartext signatures; all other PGP versions do it this way too.

#no-escape-from-lines

# If you do not use the Latin-1 (ISO-8859-1) charset, you should tell
# GnuPG which is the native character set. Please check the man page
# for supported character sets. This character set is only used for
# metadata and not for the actual message which does not undergo any
# translation. Note that future version of GnuPG will change to UTF-8
# as default character set. In most cases this option is not required
# as GnuPG is able to figure out the correct charset at runtime.

#charset utf-8

# Group names may be defined like this:
# group mynames = paige 0x12345678 joe patti
#
# Any time "mynames" is a recipient (-r or --recipient), it will be
# expanded to the names "paige", "joe", and "patti", and the key ID
# "0x12345678". Note there is only one level of expansion - you
# cannot make an group that points to another group. Note also that
# if there are spaces in the recipient name, this will appear as two
# recipients. In these cases it is better to use the key ID.

#group mynames = paige 0x12345678 joe patti

# Lock the file only once for the lifetime of a process. If you do
# not define this, the lock will be obtained and released every time
# it is needed, which is usually preferable.

#lock-once

# GnuPG can send and receive keys to and from a keyserver. These
# servers can be HKP, email, or LDAP (if GnuPG is built with LDAP
# support).
#
# Example HKP keyserver:
# hkp://subkeys.pgp.net
#
# Example email keyserver:
# mailto:pgp-public-keys@keys.pgp.net
#
# Example LDAP keyservers:
# ldap://keyserver.pgp.com
#
# Regular URL syntax applies, and you can set an alternate port
# through the usual method:
# hkp://keyserver.example.net:22742
#
# Most users just set the name and type of their preferred keyserver.
# Note that most servers (with the notable exception of
# ldap://keyserver.pgp.com) synchronize changes with each other. Note
# also that a single server name may actually point to multiple
# servers via DNS round-robin. hkp://subkeys.pgp.net is an example of
# such a "server", which spreads the load over a number of physical
# servers.

keyserver hkp://subkeys.pgp.net
#keyserver mailto:pgp-public-keys@keys.nl.pgp.net
#keyserver ldap://keyserver.pgp.com

# Common options for keyserver functions:
#
# include-disabled : when searching, include keys marked as "disabled"
# on the keyserver (not all keyservers support this).
#
# no-include-revoked : when searching, do not include keys marked as
# "revoked" on the keyserver.
#
# verbose : show more information as the keys are fetched.
# Can be used more than once to increase the amount
# of information shown.
#
# use-temp-files : use temporary files instead of a pipe to talk to the
# keyserver. Some platforms (Win32 for one) always
# have this on.
#
# keep-temp-files : do not delete temporary files after using them
# (really only useful for debugging)
#
# http-proxy="proxy" : set the proxy to use for HTTP and HKP keyservers.
# This overrides the "http_proxy" environment variable,
# if any.
#
# auto-key-retrieve : automatically fetch keys as needed from the keyserver
# when verifying signatures or when importing keys that
# have been revoked by a revocation key that is not
# present on the keyring.
#
# no-include-attributes : do not include attribute IDs (aka "photo IDs")
# when sending keys to the keyserver.

#keyserver-options auto-key-retrieve

# Display photo user IDs in key listings

# list-options show-photos

# Display photo user IDs when a signature from a key with a photo is
# verified

# verify-options show-photos

# Use this program to display photo user IDs
#
# %i is expanded to a temporary file that contains the photo.
# %I is the same as %i, but the file isn't deleted afterwards by GnuPG.
# %k is expanded to the key ID of the key.
# %K is expanded to the long OpenPGP key ID of the key.
# %t is expanded to the extension of the image (e.g. "jpg").
# %T is expanded to the MIME type of the image (e.g. "image/jpeg").
# %f is expanded to the fingerprint of the key.
# %% is %, of course.
#
# If %i or %I are not present, then the photo is supplied to the
# viewer on standard input. If your platform supports it, standard
# input is the best way to do this as it avoids the time and effort in
# generating and then cleaning up a secure temp file.
#
# If no photo-viewer is provided, GnuPG will look for xloadimage, eog,
# or display (ImageMagick). On Mac OS X and Windows, the default is
# to use your regular JPEG image viewer.
#
# Some other viewers:
# photo-viewer "qiv %i"
# photo-viewer "ee %i"
#
# This one saves a copy of the photo ID in your home directory:
# photo-viewer "cat > ~/photoid-for-key-%k.%t"
#
# Use your MIME handler to view photos:
# photo-viewer "metamail -q -d -b -c %T -s 'KeyID 0x%k' -f GnuPG"

# Passphrase agent
#
# We support the old experimental passphrase agent protocol as well as
# the new Assuan based one (currently available in the "newpg" package
# at ftp.gnupg.org/gcrypt/alpha/aegypten/). To make use of the agent,
# you have to run an agent as daemon and use the option
#
# use-agent
#
# which tries to use the agent but will fallback to the regular mode
# if there is a problem connecting to the agent. The normal way to
# locate the agent is by looking at the environment variable
# GPG_AGENT_INFO which should have been set during gpg-agent startup.
# In certain situations the use of this variable is not possible, thus
# the option
#
# --gpg-agent-info=<path>:<pid>:1
#
# may be used to override it.

# Automatic key location
#
# GnuPG can automatically locate and retrieve keys as needed using the
# auto-key-locate option. This happens when encrypting to an email
# address (in the "user@example.com" form), and there are no
# user@example.com keys on the local keyring. This option takes the
# following arguments, in the order they are to be tried:
#
# cert = locate a key using DNS CERT, as specified in RFC-4398.
# GnuPG can handle both the PGP (key) and IPGP (URL + fingerprint)
# CERT methods.
#
# pka = locate a key using DNS PKA.
#
# ldap = locate a key using the PGP Universal method of checking
# "ldap://keys.(thedomain)". For example, encrypting to
# user@example.com will check ldap://keys.example.com.
#
# keyserver = locate a key using whatever keyserver is defined using
# the keyserver option.
#
# You may also list arbitrary keyservers here by URL.
#
# Try CERT, then PKA, then LDAP, then hkp://subkeys.net:
#auto-key-locate cert pka ldap hkp://subkeys.pgp.net

Mit ps -e finde irgendwie nicht raus mit welchen Rechten httpd läuft, aber top sagt www, was ja passen würde.
 
So wie es aussieht, dürfte dann die Ursache in der Konfiguration von PHP oder Restriktionen seitens des Webservers liegen. Dann könnte man höchstens noch versuchen die Sache dadurch zu umgehen, daß man den Befehl in ein Skript packt und dieses mit 'bash skriptname.sh' aufruft. Wenn das auch nicht hilft, müsstest du den Safe-Mode von PHP deaktivieren und davon würde ich abraten. Alternativ gibst du dem Webserver-User sudo-Rechte auf gpg und rufst gpg dann über sudo auf. Der sauberste Weg dürfte aber vermutlich das PEAR-Paket für GPG sein.
 
Ein kleines chown auf /root usw hilt auch wahre Wunder :D
Das mit dem Script könnte auch klappen, das werd ich mir morgen mal anschauen. Jetzt mag ich nicht mehr. Ich habe immer noch die Vermutung daß mit der Installation von gnupg irgendwas nicht stimmt. Vielleicht findet sich ja jemand der es bei seinem Server mal ausprobiert ob er schafft gpg aufzurufen.
Das mit dem PEAR Paket hab ich mir auch schon überlegt, aber das bringt wieder andere Probleme mit sich. Ausserdem soll das ganz ja ganz schnell auf einem anderen Webserver zum laufen gebracht werden. Da will sicher keiner irgendwelche Pakete installieren.
Trotzdem Danke bitmuncher!

Gruß odigo
 
Zurück
Oben