Bon les gars c'est gentil de s'interesser à mon problème... mais **concrêtement** vous feriez quoi ?
Si tu veux quelqu'un qui t'aide, qui te donne use solution clé en main, et sur qui tu puisse râler si ça marche pas ? **concrêtement**, je passerai par une SSII ou une SSLL.
Bon les gars c'est gentil de s'interesser à mon problème... mais
**concrêtement** vous feriez quoi ?
Si tu veux quelqu'un qui t'aide, qui te donne use solution clé en
main, et sur qui tu puisse râler si ça marche pas ? **concrêtement**,
je passerai par une SSII ou une SSLL.
Bon les gars c'est gentil de s'interesser à mon problème... mais **concrêtement** vous feriez quoi ?
Si tu veux quelqu'un qui t'aide, qui te donne use solution clé en main, et sur qui tu puisse râler si ça marche pas ? **concrêtement**, je passerai par une SSII ou une SSLL.
-- Matthieu
Arol
"Matthieu Moy" a écrit dans le message de news:
Bon les gars c'est gentil de s'interesser à mon problème... mais **concrêtement** vous feriez quoi ?
Si tu veux quelqu'un qui t'aide, qui te donne use solution clé en main, et sur qui tu puisse râler si ça marche pas ? **concrêtement**, je passerai par une SSII ou une SSLL.
Il y en a qui croient encore au père noël.
"Matthieu Moy" a écrit dans le message de news:
Bon les gars c'est gentil de s'interesser à mon problème... mais
**concrêtement** vous feriez quoi ?
Si tu veux quelqu'un qui t'aide, qui te donne use solution clé en
main, et sur qui tu puisse râler si ça marche pas ? **concrêtement**,
je passerai par une SSII ou une SSLL.
Bon les gars c'est gentil de s'interesser à mon problème... mais **concrêtement** vous feriez quoi ?
Si tu veux quelqu'un qui t'aide, qui te donne use solution clé en main, et sur qui tu puisse râler si ça marche pas ? **concrêtement**, je passerai par une SSII ou une SSLL.
Il y en a qui croient encore au père noël.
Sébastien Monbrun aka TiChou
Dans le message <news:4447dd14$0$19678$, ** tapota sur f.c.o.l.configuration :
Bon les gars c'est gentil de s'interesser à mon problème...
Pas de quoi. ;-)
mais **concrêtement** vous feriez quoi ?
Lire la doc et les nombreux exemples. :-)
-- Sébastien Monbrun aka TiChou
Dans le message <news:4447dd14$0$19678$8fcfb975@news.wanadoo.fr>,
*noone@nowhere.undef* tapota sur f.c.o.l.configuration :
Bon les gars c'est gentil de s'interesser à mon problème...
Dans le message <news:4447dd14$0$19678$, ** tapota sur f.c.o.l.configuration :
Bon les gars c'est gentil de s'interesser à mon problème...
Pas de quoi. ;-)
mais **concrêtement** vous feriez quoi ?
Lire la doc et les nombreux exemples. :-)
-- Sébastien Monbrun aka TiChou
noone
Bon les gars c'est gentil de s'interesser à mon problème... mais **concrêtement** vous feriez quoi ?
Si tu veux quelqu'un qui t'aide, qui te donne use solution clé en main, et sur qui tu puisse râler si ça marche pas ? **concrêtement**, je passerai par une SSII ou une SSLL.
Ce que je veux savoir c'est si vous pensez que la modif de /etc/sudoers citée précédement(*) est judicieuse et qu'une simple authentification par un htaccess pour accéder à la page d'administration est une bonne idée (attention ! je ne dis pas la **meilleure** idée...)
(*)
dans /etc/sudoers je mets
apache ALL=(root) NOPASSWD: /path/to/my_script.sh
dans PHP
je fais
exec(sudo /path/to/my_script.sh);
et ça suffit ?
Bon les gars c'est gentil de s'interesser à mon problème... mais
**concrêtement** vous feriez quoi ?
Si tu veux quelqu'un qui t'aide, qui te donne use solution clé en
main, et sur qui tu puisse râler si ça marche pas ? **concrêtement**,
je passerai par une SSII ou une SSLL.
Ce que je veux savoir c'est si vous pensez que la modif de /etc/sudoers
citée précédement(*) est judicieuse et qu'une simple authentification
par un htaccess pour accéder à la page d'administration est une bonne
idée (attention ! je ne dis pas la **meilleure** idée...)
Bon les gars c'est gentil de s'interesser à mon problème... mais **concrêtement** vous feriez quoi ?
Si tu veux quelqu'un qui t'aide, qui te donne use solution clé en main, et sur qui tu puisse râler si ça marche pas ? **concrêtement**, je passerai par une SSII ou une SSLL.
Ce que je veux savoir c'est si vous pensez que la modif de /etc/sudoers citée précédement(*) est judicieuse et qu'une simple authentification par un htaccess pour accéder à la page d'administration est une bonne idée (attention ! je ne dis pas la **meilleure** idée...)
(*)
dans /etc/sudoers je mets
apache ALL=(root) NOPASSWD: /path/to/my_script.sh
dans PHP
je fais
exec(sudo /path/to/my_script.sh);
et ça suffit ?
Sébastien Monbrun aka TiChou
Dans le message <news:4447edfe$0$20174$, ** tapota sur f.c.o.l.configuration :
dans /etc/sudoers je mets
apache ALL=(root) NOPASSWD: /path/to/my_script.sh
C'est bien, vous avez lu et compris la doc. :-)
dans PHP je fais
exec(sudo /path/to/my_script.sh);
Ne pas oublier les (doubles) quotes.
et ça suffit ?
Sur le principe, ouais.
-- Sébastien Monbrun aka TiChou
Dans le message <news:4447edfe$0$20174$8fcfb975@news.wanadoo.fr>,
*noone@nowhere.undef* tapota sur f.c.o.l.configuration :
dans PHP je fais exec(sudo /path/to/my_script.sh); Ne pas oublier les (doubles) quotes.
oui c'est un oubli...
et ça suffit ? Sur le principe, ouais.
Merci
Sébastien Monbrun aka TiChou
Dans le message <news:, *Fabien LE LEZ* tapota sur f.c.o.l.configuration :
Alors il y a mieux : le certificat SSL.
Pour identifier qui ou quoi ?
Pour authentifier l'utilisateur autorisé à lancer le script PHP et indirectement le script shell, et/ou à chiffrer les échanges entre le script PHP et le script shell, tout dépend du scénario.
Premier scénario : l'accès au script PHP se fait via HTTPS et avec un utilisateur authentifié avec son certificat. Le script PHP transmet alors au script shell, via soit l'environnement, soit une session PHP ou soit en argument, la variable SSL_CLIENT_CERT ou SSL_CLIENT_S_DN(_CN). Ensuite, le script shell vérifie qu'il s'agit bien du bon utilisateur avant d'exécuter le reste. Pour plus de sécurité, on peut chiffrer la transmission de la variable avec un bi-clé pour éviter que la variable soit vue en clair en cas d'interception.
Deuxième scénario qui me parait plus robuste : on utilise suEXEC. On place le script PHP seul dans un vhost avec un uid et gid unique. Déjà, ça permet d'interdire l'accès au script par quiconque (sauf root bien évidement). Ensuite, rendre accessible ce vhost uniquement en HTTPS et à un utilisateur authentifié avec son certificat. Enfin, on configure sudo pour que seul l'uid/gid du vhost puisse lancer le script shell.
-- Sébastien Monbrun aka TiChou
Dans le message <news:nklf42pb80fi74hcpcp3419evka5iigl7o@4ax.com>,
*Fabien LE LEZ* tapota sur f.c.o.l.configuration :
Alors il y a mieux : le certificat SSL.
Pour identifier qui ou quoi ?
Pour authentifier l'utilisateur autorisé à lancer le script PHP et
indirectement le script shell, et/ou à chiffrer les échanges entre le script
PHP et le script shell, tout dépend du scénario.
Premier scénario : l'accès au script PHP se fait via HTTPS et avec un
utilisateur authentifié avec son certificat. Le script PHP transmet alors au
script shell, via soit l'environnement, soit une session PHP ou soit en
argument, la variable SSL_CLIENT_CERT ou SSL_CLIENT_S_DN(_CN). Ensuite, le
script shell vérifie qu'il s'agit bien du bon utilisateur avant d'exécuter
le reste. Pour plus de sécurité, on peut chiffrer la transmission de la
variable avec un bi-clé pour éviter que la variable soit vue en clair en cas
d'interception.
Deuxième scénario qui me parait plus robuste : on utilise suEXEC. On place
le script PHP seul dans un vhost avec un uid et gid unique. Déjà, ça permet
d'interdire l'accès au script par quiconque (sauf root bien évidement).
Ensuite, rendre accessible ce vhost uniquement en HTTPS et à un utilisateur
authentifié avec son certificat. Enfin, on configure sudo pour que seul
l'uid/gid du vhost puisse lancer le script shell.
Dans le message <news:, *Fabien LE LEZ* tapota sur f.c.o.l.configuration :
Alors il y a mieux : le certificat SSL.
Pour identifier qui ou quoi ?
Pour authentifier l'utilisateur autorisé à lancer le script PHP et indirectement le script shell, et/ou à chiffrer les échanges entre le script PHP et le script shell, tout dépend du scénario.
Premier scénario : l'accès au script PHP se fait via HTTPS et avec un utilisateur authentifié avec son certificat. Le script PHP transmet alors au script shell, via soit l'environnement, soit une session PHP ou soit en argument, la variable SSL_CLIENT_CERT ou SSL_CLIENT_S_DN(_CN). Ensuite, le script shell vérifie qu'il s'agit bien du bon utilisateur avant d'exécuter le reste. Pour plus de sécurité, on peut chiffrer la transmission de la variable avec un bi-clé pour éviter que la variable soit vue en clair en cas d'interception.
Deuxième scénario qui me parait plus robuste : on utilise suEXEC. On place le script PHP seul dans un vhost avec un uid et gid unique. Déjà, ça permet d'interdire l'accès au script par quiconque (sauf root bien évidement). Ensuite, rendre accessible ce vhost uniquement en HTTPS et à un utilisateur authentifié avec son certificat. Enfin, on configure sudo pour que seul l'uid/gid du vhost puisse lancer le script shell.
