Ma société dispose d'un service d'hébergement Web pour lequel les gens s'inscrivent. Une fois le processus d’inscription terminé, nous entrons manuellement et créons un environnement de test/dev que ce client pourra utiliser. Généralement, le processus se déroule comme suit:
somerandomstring.devserver.com
Même si nous utilisons des scripts à cette fin, volume indique qu’il est désormais fastidieux de se connecter et de les exécuter manuellement. Nous voulons donc automatiser ce processus pour qu'il soit déclenché immédiatement après la fin du processus d'inscription du client.
J'ai pensé à plusieurs façons de gérer cela.
1) Donnez à l'utilisateur la capacité adduser
et utilisez la fonction PHP exec()
pour créer cet utilisateur. Je devrais donner cette capacité à www-data
cependant, non? Avec PHP exécuté en mode sans échec, les commandes pour exec () sont limitées à un répertoire spécifié. Donc, si je devais copier/usr/sbin/adduser dans/my/custom/dir où seule cette commande est disponible, quels seraient les problèmes de sécurité persistants? Je ne comprends toujours pas comment je mettrais à jour le dossier sites-available avec le nouveau site, puisque ceux-ci appartiennent à root.
2) Laisser cron le faire: une personne doit s'inscrire au service. Par conséquent, elle a par défaut un nom d'utilisateur et d'autres données client stockées dans mysql. À partir d'un compte disposant des fonctionnalités adduser
, demandez à cron d'exécuter un script de routine qui recherche de nouveaux comptes (peut-être toutes les 30 à 60 secondes). Si vous en trouvez, créez un compte linux pour eux, remplissez les répertoires de base, écrivez le fichier virtualhost de conf Apache et rechargez Apache.
L'option 2 semble être le moyen le plus sûr, car un compte administrateur isolé le gère sans que www-data ou le site Web ait à exécuter des scripts et des programmes système. Le problème est le lot. De préférence, j'aimerais rechercher une solution option 1 afin qu'un client soit immédiatement connecté et redirigé vers son instance de serveur installée et prête à être utilisée. De plus, je n'aime pas trop le fait de devoir recharger/redémarrer Apache.
Les entreprises le font tous les jours, en particulier les sociétés d’hébergement Web. Bluehost, par exemple, une fois que vous avez terminé le processus d'inscription, vous avez immédiatement accès à/home/user/public_html avec lequel vous pouvez interagir. Étant donné que des solutions commerciales existent, je suis convaincu que beaucoup d’attention a été donnée à la manière de la réaliser en toute sécurité. Ce que j'essaie d'accomplir est identique, mais à une échelle beaucoup plus petite.
⚠
WARNING
⚠Il s'agit d'un risque de sécurité inhérent et présente un potentiel d'aller au sud à tout moment. Je déconseillerais fortement cette configuration, mais bon.
Je ne suis pas responsable de ce qui se passe si vous suivez les instructions données dans ce message, et je ne vous conseille pas de suivre ce système. Ceci est principalement à des fins éducatives/de recherche.
Linux a ce qu'on appelle setuid
qui permet à tout programme donné (comme Sudo
) de s'exécuter avec des privilèges supérieurs à ceux de l'utilisateur en cours d'exécution. Vous pouvez écrire un script Shell pour faire tout ce dont vous avez besoin.
À partir de là, les scripts Shell ne pouvant pas être setuid
, vous devez convertir cela en binaire. Vous pouvez utiliser quelque chose comme shc
pour cela.
Une fois que vous avez votre pseudo-binaire Shell (nom d’exemple: bootstrap_user
) contenant tout ce dont vous avez besoin, vous pouvez procéder à des modifications amusantes pour le préparer. À savoir, ceci:
Définissez-le appartenant à root
et au groupe www-data
.
chown root:www-data ./bootstrap_user
Affectez des permanentes RWX pour le propriétaire (root), lisez et exécutez pour le groupe, aucune pour quiconque:
chmod 750 ./bootstrap_user
Déplacez le binaire quelque part PHP peut exec()
it.
Enfin, ajoutez-y le bit setuid
, afin qu’il soit exécuté en tant que root:
chmod u+s ./bootstrap_user
En PHP, vous pouvez maintenant appeler bootstrap_user
comme exécutable, en transmettant les paramètres requis. Assurez-vous de vous échapper et de désinfecter vos données.
Je pense que je me méfierais de tout ce qui donne à un utilisateur de navigateur la possibilité de générer automatiquement un utilisateur Unix. Si vous le faites, il devrait probablement incorporer à la fois un mécanisme de mise en file d'attente, ainsi qu'un journal ou une base de données, afin d'éviter ce qui suit:
Alors, que se passe-t-il lorsque l'utilisateur relance quelque chose qui a déjà été fait ou se produit toujours?