Journal Execution de commandes root par apache

Posté par Axel le 13 mai 2004 à 09:16.

Étiquettes : aucune

mai

2004

Bonjour,
certains diront que ce n est pas le lieu, mais l habitude est faite de poser des questions techniques dans les journaux.

Voila mon problème, j'aimerais pouvoir executer des commandes en php, seulement, ces commandes doivent etre executées en root , comme par exemple "useradd" ou autre.
J ai regardé du coté de suexec, mais il ne permet pas d executer en tant que root ou utilisateur appartenant au groupe root.

Une solution est de mettre le root comme propriétaire d apache (ou de php si php n est pas en module) (ou meme setuid apache, si jene me trompe pas)
Mais j 'aimerais à tout prix éviter d en arriver là.

Quelqu un aurait une solution pour ce problème ?

Merci d'avance.

# Cron ?

Posté par eolyte le 13 mai 2004 à 09:31. Évalué à 2.

Salut, perso pour un problème similaire, je me suis crée une petite table MySQL qui va bien, et un script bash qui parse la dite table régulièrement par l'intermédiare de cron pour créer les nouveaux utilisateurs, et virer ceux qui ont été supprimés.

C'est la solution la moins insecure que j'ai trouvée.
- [^] # Re: Cron ?
  
  Posté par Axel le 13 mai 2004 à 09:47. Évalué à 0.
  
  en fait useradd etait un exemple mais il y en a d autres, comme echo ou meme cat.
  
  Mais merci quand meme :)
# sudo

Posté par ploum (site web personnel, Mastodon) le 13 mai 2004 à 09:38. Évalué à 4.

sudo ?
Mes livres CC By-SA : https://ploum.net/livres.html
- [^] # Re: sudo
  
  Posté par Axel le 13 mai 2004 à 09:52. Évalué à 0.
  
  Oui, je pense que c est vers quoi je vais me rabattre.
  
  J ai une autre question, est il possible (j en doute, mais merci de confirmer) de chrooter apache, tout en lui laissant la possibilité d'executer des commandes modifiant le système "hôte" ?
  - [^] # Re: sudo
    
    Posté par Colin Leroy (site web personnel) le 13 mai 2004 à 11:13. Évalué à 2.
    
    Non, s'il est chrooté, il ne voit pas le système en question. Il est dans un faux / et ne peut remonter (c'est tout l'intérêt de la chose :))
# et si...

Posté par Axel le 13 mai 2004 à 09:54. Évalué à 1.

je me réponds à moi meme , mais ne serait il pas mieux (que le sudo) de mettre les commandes dans un script shell et de faire un chmod +s sur ce script ?
- [^] # Re: et si...
  
  Posté par Ben le 13 mai 2004 à 10:05. Évalué à 2.
  
  à mon avis non: avec le sudo tu peux restreindre les commandes éxécutées en tant que root. Avec ta méthode (écriture dans un script avec chmod +s), il faut que tu sois sûr du contenu de ce script, il n'y a pas de mécanisme automatique de contrôle des commandes executées.
  - [^] # Re: et si...
    
    Posté par Axel le 13 mai 2004 à 10:09. Évalué à 1.
    
    hum, c est moi qui écrit le script et je suis seul utilisateur donc l'accès à des scripts vilains est assez restreint, mais je suis d'accord.
- [^] # Re: et si...
  
  Posté par remi le 13 mai 2004 à 10:26. Évalué à 3.
  
  Tu n'a pas précisé si le système hôte est un linux ou une autre variante d'unix, mais s'il s'agit effectivement de linux, alors un petit man 2 execve devrait t'informer que linux ne tient pas compte des bits Set-UID et Set-GID pour les scripts. (bash ou autre d'ailleurs).
  
  Pour ton problème, je serais partisan de la méthode sudo, avec des scripts bien déterminés _et_ sécurisés (environnement à 0, notamment). N'autorise pas directement un sudo en root sur des choses comme cat par exemple; tu risques d'être décu niveau sécurité.
  - [^] # Re: et si...
    
    Posté par Axel le 13 mai 2004 à 10:32. Évalué à 1.
    
    qu est ce que tu entends par environnement à 0 ?
    - [^] # Re: et si...
      
      Posté par remi le 13 mai 2004 à 11:38. Évalué à 1.
      
      J'entends qu'il faut faire attention aux variables qui peuvent poser problème dans un script qui ext executé sous une autre identité. Notamment, PATH, LD_LIBRARY_PATH, ...
      
      Normalement sudo fait un certain travail sur ces variables, histoire d'éviter que du code non prévu ne soit executé.
      
      Tu peux ensuite dans ton script, ré-initialiser le PATH à une valeur sure: /bin:/usr/bin:/sbin:/usr/sbin par exemple, comme ca tu es certain de ce qui est executé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.