directadmin shell_exec

[marsipulami]

Beste WHT'ers,

ik heb debian draaien, met DA(custombuild). Het probleem is het volgende. Voor de veiligheid heb ik in de php.ini de shell_exec functie onder andere uitgezet. alleen nu komt er een domein met magento erop, en die vereist dat die functie aan staat.

Nou vind ik dat op zich geen probleem alleen hoe pak ik dit aan.

ik heb op http://help.directadmin.com/item.php?id=183 gedaan wat ze hier zeiden, voor individuele accounts,

dus in de vHost vna het domein de genoemde regel toegevoegd, in de map van directadmin/data/users/$user een php map aangemaakt met daarin een copy van de php.ini en daar wel shell_exec allowed.

nu heb ik httpd gerestart, alleen zie ik geen verandering.

wat vergeet ik?

[dennis0162]

Post de vhost eens van het domeinnaam.

[pierce]

Heb je bij de custom httpd config voor het domein aangegeven dat er een aparte php.ini is?


suPHP_ConfigPath /usr/local/directadmin/data/users/gebruikersnaam/php5

Waar "php5" de map is waar het php.ini bestand staat.

[marsipulami]

ik heb deze regel toegeveogd:

SetEnv PHP_INI_SCAN_DIR /usr/local/directadmin/data/users/|USER|/php/ aan de customhttpd
dit stond namelijk in de knowledgebase.

moet
suPHP_ConfigPath /usr/local/directadmin/data/users/gebruikersnaam/php5

die staat namelijk bij de oude manier

dan ook?

[pierce]

Sorry, dat is de oude manier zoals hieronder vermeld. Maar het werkt wel ;)


old way:

In order to setup a php.ini for each user with suPhp (installed by custombuild), edit:
/etc/httpd/conf/extra/httpd-suphp.conf

Find this line:
suPHP_ConfigPath /usr/local/etc/php5/cgi/

and comment it out by changing it to
#suPHP_ConfigPath /usr/local/etc/php5/cgi/

(just add a # in front of it).

Doing this will let suPhp be more flexible in using a different php.ini file. By default, it will still fall back to the /usr/local/etc/php5/cgi/php.ini if nothing else is set, but by not setting it, it allows us to change it (suPhp only accepts the first call of that command).

The next step is to tell apache where to find the php.ini that you want.
Go to:
Admin Level -> Custom httpd configuration -> domain.com > suPHP_ConfigPath /usr/local/directadmin/data/users/gebruikersnaam/php5

[marsipulami]

gaan we die even proberen

[marsipulami]

etc/httpd/conf/extra/httpd-suphp.conf dit bestand is leeg bij mij, ik heb suphp wel geinstalleerd.

iemand een idee?

[pierce]

dit bestand is leeg bij mij, ik heb suphp wel geinstalleerd.

iemand een idee?

probeer deze eens:

/etc/httpd/conf/extra/httpd-suphp.conf

met een slash ervoor ;)

[marsipulami]

probeer deze eens:

/etc/httpd/conf/extra/httpd-suphp.conf

met een slash ervoor ;)

nee dat had ik ook geprobeerd;) het bestand staat er wel, alleen is leeg

[mikeh]

Vaak staat er geen httpd.conf maar iets in de trand van sample-httpd.conf maar then again, ik ken suphp + config files niet.

Iemand met een beetje kennis van *nix zou zich toch wel moeten redden in zulke situaties ?

find /etc/httpd/conf | grep httpd-suphp* zou je meer duidelijkeheid kunnen geven.

[marsipulami]

find /etc/httpd/conf | grep httpd-suphp* zou je meer duidelijkeheid kunnen geven.

die komt op met dezelfde file, die leeg is

[ju5t]

Wij hebben custom ini files voor elke gebruiker, maar volgens mij moet het ook werken per gebruiker. Ik heb dit niet getest maar volgens mij moet het werken:

Wanneer je ingelogt bent als admin binnen DirectAdmin ga je naar Custom HTTPD Configurations. Daar zoek je de gebruiker op welke Magento gaat draaien en daar zet je de volgende code in het bovenste vak:


SetEnv PHP_INI_SCAN_DIR /usr/local/directadmin/data/users/|USER|/php/

In /usr/local/directadmin/data/users/|USER|/php/ maak je een nieuw .ini bestand aan, bijvoorbeeld magento.ini. Hierin zet je de alleen in wat je wilt overrulen van de default config. In jou geval dus:


disable_functions = "alle functies welke je wilt disablen, behalve shell_exec()"

Dit moet voldoende zijn. Als je nu een phpinfo() file laad onder deze gebruiker moet je het volgende zien in de bovenste sectie:


Scan this dir for additional .ini files /usr/local/directadmin/data/users/username/php/
additional .ini files parsed /usr/local/directadmin/data/users/username/php/magento.ini

[mikeh]

suphp's sample config;

http://www.suphp.org/DocumentationView.html?file=suphp.conf-example

aanvullende informatie over de config;

http://www.suphp.org/DocumentationView.html?file=CONFIG

Good luck.

[marsipulami]

@Getup dit heb ik gedaan, tevens httpd gerestart, alleen geeft hij in de phpinfo niets.

Scan this dir for additional .ini files (none)

@mikeh
die had ik ook al gevonden, alleen wanneer ik de sample gebruik(die volgens mij niet veranderd hoeft te worden) start httpd niet meer

[Spyder01]

Zet dit er eens in en niet meer dan dit:

<IfModule mod_suphp.c>
<FilesMatch "\.(inc|php|php3|php4|php5|php6|phtml|phps)$">
AddHandler x-httpd-php5 .inc .php .php3 .php4 .php5 .phtml
</FilesMatch>
<Location />
suPHP_Engine on
suPHP_ConfigPath /usr/local/etc/php5/cgi/
suPHP_AddHandler x-httpd-php5
</Location>
</IfModule>


Let erop dat je het ConfigPath vermoedelijk wel aan moet passen in jouw situatie. Check dus even of het Path bij jou klopt.

Daarna dit erin zetten, httpd restarten en kijken wat hij doet. Start hij zonder problemen, dan de benodigde aanpassingen doen.

Volgens mij heb je ook aardig zitten klooien.

[Geert-Jan]

en alweer mis ik of php onder _CLI draait of _CGI. Wanneer php onder _CGI draait, is het toch heel eenvoudig iedere user zijn eigen php.ini mee te geven, en dan voor deze gebruiker dat toe te staan??

automate creation of per user php.ini for new users
Code:


# touch /usr/local/directadmin/scripts/custom/user_create_post.sh
# chmod 755 /usr/local/directadmin/scripts/custom/user_create_post.sh
# nano /usr/local/directadmin/scripts/custom/user_create_post.sh


use the following shell script:
Code:


#!/bin/sh

touch /home/$username/php.ini
echo "open_basedir = /home/$username/:/tmp/" >> /home/$username/php.ini
chown root:root /home/$username/php.ini

exit 0;



create php.ini files for current users
Code:


# ls -l /home | grep '^d' | awk '{system("username="$3" /usr/local/directadmin/scripts/custom/user_create_post.sh")}'

[marsipulami]

ik heb volgens mijn options.conf van da custombuild cli geactiveerd. ik krijg het vermoeden dat dit niet mag voor suphp?

klopt dit? dan ga ik dat eerst veranderen

[pierce]

ik heb volgens mijn options.conf van da custombuild cli geactiveerd. ik krijg het vermoeden dat dit niet mag voor suphp?

klopt dit? dan ga ik dat eerst veranderen

Doe dat :)

Hou je er wel rekening mee dat je websites dan tijdelijk niet bereikbaar kunnen zijn.

[marsipulami]

ga ik deze week een keer een nachtje aan besteden ;)

[Geert-Jan]

Pfff, half uurtje werk naar _cli. Van _cli naar _cgi een uurtje, incl. alles omzetten en controleren.
Alleen PHP sites zouden even een dipje kunnen hebben, meer niet.

[marsipulami]

ik bedoel in de zin van, snachts wordt er niet veel gebruik van gemaakt over het algemeen. dus ik doe het snachts:p

[ju5t]

use the following shell script:
Code:


#!/bin/sh

touch /home/$username/php.ini
echo "open_basedir = /home/$username/:/tmp/" >> /home/$username/php.ini
chown root:root /home/$username/php.ini

exit 0;



Dit is verreweg de slechtste implementatie voor custom .ini files wanneer je gebruik maakt van PHP_INI_SCAN_DIR. Dit zal alle .ini files laden uit /home/username/. Het chownen naar root is schijnbeveiliging en gaat je niet helpen.

[Geert-Jan]

Het is ook een deel van...
Maar goed, hoe zou jij het doen?

[ju5t]

Maar dat deel is wel gelijk datgene wat er voor zorgt dat alle andere beveiligingen als een disable_functions meteen omzeild kunnen worden ;-)

Wij hebben custom ini files staan in /usr/local/directadmin/data/users/$username/php/. Zoals ik ook al eerder hier in het voorbeeld had staan. Onze user_create_post.sh ziet er dan ook als volgt uit:


#!/bin/sh

# create custom temp directory
rm -rf /home/$username/tmp
mkdir -p /home/$username/tmp
chown -R $username:$username /home/$username/tmp
chmod 755 /home/$username/tmp

# create custom php.ini
rm -rf /usr/local/directadmin/data/users/$username/php/
mkdir /usr/local/directadmin/data/users/$username/php/
chown $username:$username /usr/local/directadmin/data/users/$username/php/
touch /usr/local/directadmin/data/users/$username/php/php.ini
echo "open_basedir = /home/$username/:/tmp/:/var/www/html/" >> /usr/local/directadmin/data/users/$username/php/php.ini
echo "upload_tmp_dir = /home/$username/tmp/" >> /usr/local/directadmin/data/users/$username/php/php.ini
echo "session.save_path = /home/$username/tmp/" >> /usr/local/directadmin/data/users/$username/php/php.ini
chown root:root /usr/local/directadmin/data/users/$username/php/php.ini
chattr +i /usr/local/directadmin/data/users/$username/php/

exit 0;

Vanwege de attribute wijziging moet ook user_destroy_pre.sh aangemaakt worden met:


#!/bin/sh
chattr -i /usr/local/directadmin/data/users/$username/php/

exit 0;

[Randy]

Denk er even aan om popen ook niet te disablen, die functie heb je nodig voor Magento Connect.

[marsipulami]

ik heb cli omgezet naar cgi. Tot nu toe geen echte problemen gevonden.
alleen doet webmail.domein.nl het niet meer.

ik meende er iets overgelezen te hebben hier op het forum, maar kan het niet weer vinden.
iemand een idee waarom dat niet meer werkt, en hoe ik dat zou kunnen oplossen?

[dennis0162]

chown -R webapps:webapps /var/www/html/squirrelmail
chown -R webapps:webapps /var/www/html/webmail

[marsipulami]

voordat je gepost had heb ik de tut van de knowledgebase uitgevoerd, en nu krijg ik een 404 error op de gewone www.domein.nl PHP pagina's :s

enig idee waar dat wegkomt?

[marsipulami]

ik kan mijn post niet bewerken, maar gewoon aangemaakte subdomeinen werken wel. dus daar doet php het wel

[marsipulami]

probleem opgelost, had een fout gemaakt met de virtual_host. een oude gebruikt :$

ik ga nu slapen weltrusten