Salut !
Je cherche à lancer un serveur X, j’ai donc créer un utilisateur X pour le lancer à partir de celui-ci (et non de root).
J’ai utilisé l’option “-s /bin/false” à la création de l’utilisateur pour qu’il ne puisse pas avoir de shell.
Ma question est: comment lancer mon serveur (commande: ./X) à partir de l’utilisateur X?
Merci d’avance !
Cordialement,
Bastien
ps: je suis sous Debian Etch
ps2: “su teamspeak” ne marche pas car il n’a pas de shell correct
su startx
si tu n’a pas de gestionnaire de session …
oups en relisant je comprend la confusion.
en fait il s’agit d’un serveur quelconque (teamspeak en l’occurence), j’avais mis X car l’intérêt était moindre, j’avais oublié Xorg…
sudo -u “ton_user” "ton_soft"
mais si tu as bin false, certains programmes ne marche pas.
Effectivement, pour pouvoir lancer mon serveur il me fallait le shell.
J’ai donc remis le shell “/bin/bash” et exécuté le serveur à partir de celui-ci.
Mais je trouve ça pas terrible que l’utilisateur teamspeak puisse se connecter sur mon serveur…
[quote="doobinay"]Mais je trouve ça pas terrible que l'utilisateur teamspeak puisse se connecter sur mon serveur...[/quote]
Ben s'il n'a pas de mot de passe il aura du mal.
Sinon, si ton utilisateur ne sert qu'à lancer un script, tu dois pouvoir lui donner le script en question comme shell. Il faut peut-être le rajouter dans /etc/shells pour que ça fonctionne. À confirmer...Ben s’il n’a pas de mot de passe il aura du mal.
Sinon, si ton utilisateur ne sert qu’à lancer un script, tu dois pouvoir lui donner le script en question comme shell. Il faut peut-être le rajouter dans /etc/shells pour que ça fonctionne. À confirmer…
Je pense que ceci peut fortement t’intéresser pour ton problème : fr.wikipedia.org/wiki/Setuid
L’idée c’est de lancer le serveur X avec les droits du root sans être root, et sans utiliser “su” ou “sudo” (qui pour moi sont très dangereux).
Tiens nous au courant de ce que ça donne.
En quoi le setuid est moins dangereux ?
“sudo” est dangereux car pendant plusieurs minutes (au moins une dizaine je crois, ça dépend des versions), on peut exécuter n’importe quelle commande en tant que root. Heureusement, à la fin du temps impartit, la session est automatiquement fermée.
“su” est encore plus dangereux puisqu’une fois qu’on a ouvert la session root, il faut la fermer manuellement. Le temps qu’on ne l’a pas fait, n’importe quelle commande peut est exécutée en root, sans limitation de temps… Seul le mode root graphique fait pire.
“setuid” permet de donner les privilèges root pour une commande, et pas toutes les commandes d’un coup. Ainsi, on limite la portée des privilèges à un seul processus et on ne peut donc pas exécuter autre chose que ce que contient le programme (sauf bug de conception, mais on se place dans un cadre sain). Le temps qu’on ne pourra pas modifier le fichier qui s’exécute avec un setuid (et pour peu que ce fichier soit bien conçu), on ne mettra pas le système en péril, ce qui n’est pas du tout le cas si on peut exécuter n’importe quelle commande comme dans le cas de “su” ou “sudo”.
Avec l’option -c, tu peux utiliser su pour lancer une seule commande, rien ne t’oblige à lancer une session. Sinon, bah suffit de quitter la session quand tu quittes ton poste.
Concernant sudo, tu n’es pas obligé de l’utiliser « à la ubuntu ». Tu peux le restreindre à une seule commande, à un seul utilisateur ou groupe, tu peux régler le timeout à zéro, et plein d’autres choses… Avec suid tu restreint à une commande, mais tout le monde peut l’utiliser avec les droits root sans donner de mot de passe !
Je ne savais pas, voilà une option fort intéressante ! On ferait toujours mieux de lire entièrement le manuel d’une commande avant d’en parler.
C’est là tout le problème. Il faut penser à le faire. Un oubli peut alors coûter très cher…
Si on le paramètre correctement alors là OK. Mais le problème c’est que la configuration par défaut (utilisée par la majorité des personnes) est plutôt mauvaise.
Oui, mais si la commande n’est pas dangeureuse par nature ça ne pose pas spécialement de problème, tout dépend de ce qu’on y met derrière. Mettre un setuid sur un logiciel de mises à jour permet d’administrer la totalité du système et donc de faire tout ce qu’on veut ; mettre un setuid sur le serveur X ne pose en revanche aucun problème de sécurité (sauf bug dans le serveur X, mais c’est un autre problème).
Je m’inscruste dans votre post car je trouve l’option -c intéressante et je la vois pas dans le man de sudo… auriez-vous un bon tuto sur sudo, su car cela me semble très important pour moi enfin.
Merci
Je m’inscruste dans votre post car je trouve l’option -c intéressante et je la vois pas dans le man de sudo… auriez-vous un bon tuto sur sudo, su car cela me semble très important pour moi enfin.
Merci[/quote]
c’est normal, c’est pas une option de sudo, mais de su.
oups autant pour moi… 