Si c'est si simple, je veux bien que tu nous fasses un patch :-)
Pour etre un peu plus precis, sans avoir une infrastructure qui inspect les requetes faite par DRI, il est impossible d'avoir la moindre forme de securite. C'est une des raisons de l'existence des resistances a WebGL entre autre, car cela par du principe que tu ne peux pas faire de DMA et que ton architecture qui tappe directement dans le hw ne peut pas etre contourne. Si tu desactives l'acceleration hardware, le probleme ne se pose plus bien evidemment.
La seconde raison, c'est les input, tu ne veux pas que tous les process qui sont execute sous ton identite d'utilisateur, puisse contourner le dispatching de ton systeme graphique et devenir des troyans (Sous X c'est pas un vrai probleme, puisque de toute facon, tu n'as pas de securite). Il te faut donc un process que tu vas truste, qui va faire le dispatching du fd d'input et s'assurer que tout le monde coopere.
Maintenant, tu rajoutes a tout ca le fait que les gens veulent pouvoir avoir du multi utilisateurs, ce qui impose un process affichant une interface sous une entite differente que l'utilisateur finale. Il faut donc demarrer X sous un user different de l'utilisateur finale. Une fois l'authentification faite, tuer X, redemmarrer X sous le bon utilisateur et refiler le dit fd d'input. Et bien entendu, il faut aussi gerer ca quand tu te logges en console...
Donc il te faut un process commun qui se charge de demarrer tes consoles et ton login manager, tourne avec des droits d'execution superieur et peu etre truste. Etant donne que systemd est la seule solution qui implemente deja la majorite du besoin sous Linux, il est plus simple de lui ajouter ce qu'il manque (dans logind) que de reinventer une roue pour arriver au meme resultat.
[^] # Re: troll velu avec systemd
Posté par cedric . En réponse au journal Sur systemd, btrfs & co. Évalué à 10.
Si c'est si simple, je veux bien que tu nous fasses un patch :-)
Pour etre un peu plus precis, sans avoir une infrastructure qui inspect les requetes faite par DRI, il est impossible d'avoir la moindre forme de securite. C'est une des raisons de l'existence des resistances a WebGL entre autre, car cela par du principe que tu ne peux pas faire de DMA et que ton architecture qui tappe directement dans le hw ne peut pas etre contourne. Si tu desactives l'acceleration hardware, le probleme ne se pose plus bien evidemment.
La seconde raison, c'est les input, tu ne veux pas que tous les process qui sont execute sous ton identite d'utilisateur, puisse contourner le dispatching de ton systeme graphique et devenir des troyans (Sous X c'est pas un vrai probleme, puisque de toute facon, tu n'as pas de securite). Il te faut donc un process que tu vas truste, qui va faire le dispatching du fd d'input et s'assurer que tout le monde coopere.
Maintenant, tu rajoutes a tout ca le fait que les gens veulent pouvoir avoir du multi utilisateurs, ce qui impose un process affichant une interface sous une entite differente que l'utilisateur finale. Il faut donc demarrer X sous un user different de l'utilisateur finale. Une fois l'authentification faite, tuer X, redemmarrer X sous le bon utilisateur et refiler le dit fd d'input. Et bien entendu, il faut aussi gerer ca quand tu te logges en console...
Donc il te faut un process commun qui se charge de demarrer tes consoles et ton login manager, tourne avec des droits d'execution superieur et peu etre truste. Etant donne que systemd est la seule solution qui implemente deja la majorite du besoin sous Linux, il est plus simple de lui ajouter ce qu'il manque (dans logind) que de reinventer une roue pour arriver au meme resultat.