Executer Des Commandes De Coreutils D'ipkg Via Php

[Diaoul]

Salut à tous,

Je butte sur un problème assez embêtant, le voici :

Je souhaite exécuter (via la commande exec() de php) une commande que j'ai installée (df en l'occurence) via IPKG (package coreutils).

Quand je fais exec('df'), c'est /bin/df qui est executé et non pas /opt/bin/df (celui d'IPKG) ce qui est gênant car le df d'IPKG supporte l'option -P et pas celui du syno par défaut.

Je précise que /opt/bin est bien dans open_basedir du php.ini

Sur ce, je me suis dis, allons donc voir ce que donne un "which df". Et là, pas de surprise, c'est bien /bin/df.

Zut alors, je me log en shh en root, "which df" et mystère, voilà que cela me renvoi maintenant /opt/bin/df.

Mais, si je ne suis pas root, qui suis-je alors ?

echo exec('whoami');

 => nobody

Re en SSH en root, et je fais :

DiskStation> ps | grep httpd

  2758 root	   2500 S   /usr/syno/apache/bin/httpd -f /usr/syno/apache/conf/h

  2817 root	   2256 S   /usr/syno/apache/bin/httpd -f /usr/syno/apache/conf/h

  2818 root	   2232 S   /usr/syno/apache/bin/httpd -f /usr/syno/apache/conf/h

  2819 root	   6812 S   /usr/syno/apache/bin/httpd

  2903 nobody	 8892 S   /usr/syno/apache/bin/httpd

  2904 nobody	 9016 S   /usr/syno/apache/bin/httpd

  2905 nobody	 8488 S   /usr/syno/apache/bin/httpd

  2908 root	   2180 S   /usr/syno/apache/bin/httpd -f /usr/syno/apache/conf/h

  2911 nobody	 8292 S   /usr/syno/apache/bin/httpd

  2912 nobody	 8568 S   /usr/syno/apache/bin/httpd

  6906 root	   2448 S   /usr/syno/apache/bin/httpd -f /usr/syno/apache/conf/h

  7191 root	   2096 S   /usr/syno/apache/bin/httpd -f /usr/syno/apache/conf/h

  7228 root		308 S   grep httpd

C'est donc nobody qui lance les httpd, tout s'explique, encore que...

Pourquoi nobody n'a pas accès aux commandes installées par IPKG dans /opt/bin/ ?

Comment faire en sorte que l'hote virtuel "toto" accessible depuis http://ip_du_syno/toto me renvoi "toto" lorsque je fais un "exec('whoami');" ? Bref, est-ce possible d'avoir un utilisateur différent pour chaque site (et donc ainsi, limiter les droits en matière d'execution de chacun des sites indépendament) ?

Et enfin, il y a-t-il une solution élégante à mon problème ? (ie : pas me dire de faire un exec('/opt/bin/df') dans mon code (c'est pas le mien d'ailleurs ^^)).

Merci d'avance !

[hpsmartyz]

Salut,

pourquoi n'as-tu pas utilisé le package coreutils dispo en zone téléchargement, et remplacé alors

les binaires que tu voulais mettre à jour dans /bin?

et au fait, ne peux tu pas mettre le chemin complet vers /opt/bin/df dans l'appel exec?

[Diaoul]

Parce que :

1. C'est difficile de revenir en arrière après une telle manip
   
2. Un "ipkg update" + "ipkg upgrade" ne mettra pas à jour la version que j'ai dans /bin mais celle dans /opt/bin
   

Et puis, c'est pas terrible terrible

J'arrive pas à savoir pourquoi l'utilisateur nobody ne va pas me chercher df là ou il faut alors que root le fait bien...

[hpsmartyz]

Parce que :

1. C'est difficile de revenir en arrière après une telle manip
   
2. Un "ipkg update" + "ipkg upgrade" ne mettra pas à jour la version que j'ai dans /bin mais celle dans /opt/bin
   

Et puis, c'est pas terrible terrible

J'arrive pas à savoir pourquoi l'utilisateur nobody ne va pas me chercher df là ou il faut alors que root le fait bien...

j'ai dû louper qqchose.

Tu peux désinstaller coreutils (je l'ai fait une fois, pour justement utiliser les binaires compilés dispos en zone

téléchargement).

Ensuite tu va télécharger le binaire que tu veux et tu le copies en lieu et place de ton ancien 'df', par exmple

Pour ce qui est de ton autre soucis je ne sais pas trop pourquoi en ssh tu es 'nobody'.

Pour ce qui est de httpd, il tourne toujours sur nobody, c'est dans le fichier de conf.

Donc à cet égard, mais je connais pas trop les hôtes virtuels, il y a peut-être moyen de les lancer sous des noms

d'utilisateurs différents mais il ne faut à mon avis pas faire ça pour avoir accès à la bonne commande 'df'

Mieux vaut mettre le binaire que tu veux dans /bin

[Diaoul]

j'ai dû lopuer qqchose.

Tu peux désinstaller coreutils (je l'ai fait une fois, pour justement utiliser les binaires compilés dispos en zone

téléchargement)

Cela te permettra au moins d'utiliser le bon 'df'

Pour ce qui est de ton autre soucis je ne sais pas trop pourquoi en ssh tu es 'nobody'.

Pour ce qui est de httpd, il tourne toujours sur nobody, c'est dans le fichier de conf.

Donc à cet égard, mais je connais pas trop les hôtes virtuels, il y a peut-être moyen de les lancer sous des noms

d'utilisateurs différents mais il ne faut à mon avis pas faire ça pour avoir accès à la bonne commande 'df'

Mieux vaut mettre le binaire que tu veux dans /bin

Non, non, en ssh je suis en root

C'est dans php que je suis en nobody, ce qui est normal puisque httpd est lancé par nobody.

Ce qu'il faudrait faire pour faire propre et classe c'est mettre à jour cette vieille busybox... Mais je n'arrive pas à la compiler correctement :@

Nobody donne sur /sbin/nologin quand on fait un vi /etc/passwd

J'ai donc décidé de le rendre "loggable" en mettant simplement /bin/sh

Puis, "su nobody", là je fais un "which df" que vois-je ? /opt/bin/df

Tout content, je retourne sur ma page php qui fait "echo exec('which df'); et là, toujours /bin/df.....

Je résume les résultats de la commande "which df" selon l'endroit ou je le fais :

nobody en ssh => /opt/bin/df

root en ssh => /opt/bin/df

nobody via php => /bin/df

Je commence à perdre la boule

[hpsmartyz]

au fait, de quel php.ini parles tu ?

car si c'est via apache que tu testes c'est alors dans celui ci /usr/syno/etc/php.ini qu'il te faut mettre

/opt/bin dans open_basedir car c'est ce php.ini qu'apache charge via /lib/libphp5.so

si c'est un script que tu execute via /opt/bin/php alors c'est /opt/etc/php.ini qu'il faut modifier.

regarde aussi si /opt/bin est dans le PATH de nobody.

[Diaoul]

au fait, de quel php.ini parles tu ?

car si c'est via apache que tu testes c'est alors dans celui ci /usr/syno/etc/php.ini qu'il te faut mettre

/opt/bin dans open_basedir car c'est ce php.ini qu'apache charge via /lib/libphp5.so

si c'est un script que tu execute via /opt/bin/php alors c'est /opt/etc/php.ini qu'il faut modifier.

regarde aussi si /opt/bin est dans le PATH de nobody.

Je parle du php.ini du syno, vu que les commandes que j'exécute le sont via l'apache du syno, sur une page web.

/opt/bin est bien dans l'open_basedir de /usr/syno/etc/php.ini.

/opt/bin est aussi dans le path de nobody.

J'ai bien sur reboot le syno plusieurs fois, après chaque "grosse" modification.

Ca y est, tu perds la boule aussi ? ^^

[hpsmartyz]

note que tu ne serais pas confronté à cette situation si tu utilisais les binaires de la zone de téléchargement

est-ce bien le même 'nobody'?

J'ai cru lire qu'il y avait un 'Nobody' et un 'nobody'

[Diaoul]

note que tu ne serais pas confronté à cette situation si tu utilisais les binaires de la zone de téléchargement

est-ce bien le même 'nobody'?

J'ai cru lire qu'il y avait un 'Nobody' et un 'nobody'

Les binaires de la zone de téléchargement ne résistent pas à un changement de firmware, c'est plus du bidouillage qu'une véritable solution. A la limite, j'en viendrais peut être là si je ne trouve pas satisfaction.

nobody est le seul utilisateur dont je parle depuis le début, nul part je n'ai vu Nobody avec un N.

Le problème c'est surtout de savoir pourquoi ça marche en ssh et pas via PHP avec le même utilisateur à savoir nobody.

Il y a une option quelque part pour le suivi des symlinks de binaires via apache ? J'ai jeté un œil et rien vu de tel...

[Diaoul]

De même, je fais un "ps" via php (avec nobody donc) je vois que les proc de nobody (en général je ne vois que "ps"...).

Je fais pareil, en ssh avec l'utilisateur nobody, j'ai toute la liste des processus, root pas root et tout et tout

Cette fois, j'ai pas touché au "ps" donc c'est pas une question de symlink ou de /opt/bin mais bien de droits (enfin, je pense ^^)

[Diaoul]

J'ai fais quelques essais :

J'ai créé un utilisateur httpd et un groupe httpd.

Je l'ai mis dans la conf de l'utilisateur (via le fichier /usr/syno/apache/conf/httpd.conf-user)

Cette fois, j'ai bien les bons executables, sauf smartctl qui est dans /usr/syno/bin

Fort de cette expérience, j'ai testé avec root, tout marche à merveille excepté le fait que coté sécurité ben... bof bof

Il y a-t-il un moyen d'éditer les droits de l'utilisateur httpd (ou son groupe) pour lui donner des droits d'execution sur /usr/syno/bin ?

Comment faire ça ? Comment sécuriser au mieux son apache tout en permetant un minimum d'execution ? Quels risques cela comporte-t-il de faire ainsi ?

Merci =)

[PatrickH]

J'ai fais quelques essais :

J'ai créé un utilisateur httpd et un groupe httpd.

Je l'ai mis dans la conf de l'utilisateur (via le fichier /usr/syno/apache/conf/httpd.conf-user)

Cette fois, j'ai bien les bons executables, sauf smartctl qui est dans /usr/syno/bin

Fort de cette expérience, j'ai testé avec root, tout marche à merveille excepté le fait que coté sécurité ben... bof bof

Il y a-t-il un moyen d'éditer les droits de l'utilisateur httpd (ou son groupe) pour lui donner des droits d'execution sur /usr/syno/bin ?

Comment faire ça ? Comment sécuriser au mieux son apache tout en permetant un minimum d'execution ? Quels risques cela comporte-t-il de faire ainsi ?

Merci =)

Tout d'abord autoriser l'exécution de commandes système au travers de "exec" est déjà une faille de sécurité en sois, bon maintenant pourquoi ne pas créer un shell script dans lequel se trouve ta commande (quel que soit son path) shell script que tu viendrais exécuter avec "exec" ! et ne pas donner des droits "root" à apache

Patrick

[Diaoul]

Tout d'abord autoriser l'exécution de commandes système au travers de "exec" est déjà une faille de sécurité en sois, bon maintenant pourquoi ne pas créer un shell script dans lequel se trouve ta commande (quel que soit son path) shell script que tu viendrais exécuter avec "exec" ! et ne pas donner des droits "root" à apache

Patrick

En fait, pour être plus clair, je souhaiterai afficher le résultat d'une commande smartctl (smartctl --all --device marvel /dev/hda) dans une page web.

Je veux bien utiliser nobody mais il n'a pas les droits pour exécuter smartctl. Comment les lui attribuer ?

C'est pas bête de mettre tout dans un script shell, celui-ci sera bien exécuté en root ?

Merci en tout cas, je crois que je vois un début de solution

[hpsmartyz]

et la commande su ne fonctionne pas?

[Diaoul]

et la commande su ne fonctionne pas?

Dans un script shell ou via exec ? Via exec, j'ai testé, je crois que ça marche pas mais je m'y suis peut être mal pris.

[PatrickH]

Dans un script shell ou via exec ? Via exec, j'ai testé, je crois que ça marche pas mais je m'y suis peut être mal pris.

Et avec

exec("/bin/sh fichier-de-commande");

Ca marcha pas non plus ?

Patrick

[Diaoul]

Salut,

Et avec

exec("/bin/sh fichier-de-commande");

Ca marcha pas non plus ? Patrick

J'avoue que j'ai pas testé mais comme je ne peux pas (c'est deja dans un programme) toucher aux "exec(...)" en question, j'ai un peu laissé tombé le truc... Par contre, j'ai changé l'utilisateur nobody qui exécute le processus httpd (user) en un utilisateur spécialement créé pour httpd (httdp, je sais, c'est pas très original) et que j'ai mis dans un groupe éponyme. Les fonctions "df" et tout sont piochées dans /opt/bin, et "which df" me renvoie bien "opt/bin/df". J'ai donc eut ce que je voulais en changeant juste l'utilisateur. Dans le même genre, je rencontre maintenant un problème avec smartctl :

DiskStation> smartctl --all --device marvell /dev/hda

me donne bien les informations mais après avoir changé d'utilisateur :

DiskStation> su guest

et exécuté à nouveau la même commande sous cet utilisateur (avec peu de droits) :

$ smartctl --all --device marvell /dev/hda

smartctl 5.39 2009-01-14 02:39 [arm-marvell-linux-gnu] (local build)

Copyright (C) 2002-8 by Bruce Allen, http://smartmontools.sourceforge.net


Smartctl: Device Read Identity Failed (not an ATA/ATAPI device)


A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

j'obtiens donc une erreur alors que le programme est bien trouvé...

Ca le fait avec "guest" (vous pouvez tester par vous même, l'utilisateur existe déjà sur tous les Synos) mais aussi avec mon fameux utilisateur httpd.

J'ai changé les droits de smartctl en 777, pareil pour /dev/hda, rien n'y fait.

Est-ce un problème de droits ?

Comment résoudre ce petit désagrément afin d'éviter de passer forcément en root pour executer les commandes liées à S.M.A.R.T ?

Merci =)