Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un
utilisateur en faisnat la commande :
xhost +LOCAL:
Cela fonctionne à merveille.
J'ai besoin de rendre ce paramétrage automatique et je voudrais une
méthode qui marche avec gdm, kdm, xdm ou avec startx. Donc je me suis
tourné vers l'écriture du fichier X0.hosts.
J'écris dans ce fichier :
LOCAL:
Je redémarre X, mais root ne peut accéder à Xwindow, alors que quand je
fais xhost dans une console j'obtiens bien un message m'indiquant que
LOCAL: est autorisé. Pour moi, il s'agit d'un bug, non ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
YBM
Bonsoir,
Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un utilisateur en faisnat la commande : xhost +LOCAL:
ouch ! C'est pas très bon côté sécurité de jouer avec xhost...
Et pourquoi donc faire ça ? Sur Ubuntu qu'on devienne root en faisant sudo -s ou même su (en ayant mis un mot de passe au compte root) l'accès à l'affichage - qu'il soit distant ou local - fonctionne tout seul !
Bonsoir,
Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un
utilisateur en faisnat la commande :
xhost +LOCAL:
ouch ! C'est pas très bon côté sécurité de jouer avec xhost...
Et pourquoi donc faire ça ? Sur Ubuntu qu'on devienne root
en faisant sudo -s ou même su (en ayant mis un mot de passe
au compte root) l'accès à l'affichage - qu'il soit distant
ou local - fonctionne tout seul !
Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un utilisateur en faisnat la commande : xhost +LOCAL:
ouch ! C'est pas très bon côté sécurité de jouer avec xhost...
Et pourquoi donc faire ça ? Sur Ubuntu qu'on devienne root en faisant sudo -s ou même su (en ayant mis un mot de passe au compte root) l'accès à l'affichage - qu'il soit distant ou local - fonctionne tout seul !
vincent.verdon
Bonsoir,
Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un utilisateur en faisnat la commande : xhost +LOCAL:
ouch ! C'est pas très bon côté sécurité de jouer avec xhost...
Autoriser l'accès local n'est pas un gros danger.
Et pourquoi donc faire ça ? Sur Ubuntu qu'on devienne root en faisant sudo -s ou même su (en ayant mis un mot de passe au compte root) l'accès à l'affichage - qu'il soit distant ou local - fonctionne tout seul !
Je programme un daemon (logiciel Tkontrole) qui est lancé au démarrage de la machine et qui a besoin d'interragir avec l'interface graphique de n'importe quel utilisateur connecté. Je ne vois pas trop d'autre méthode pour y parvenir.
Bonsoir,
Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un
utilisateur en faisnat la commande :
xhost +LOCAL:
ouch ! C'est pas très bon côté sécurité de jouer avec xhost...
Autoriser l'accès local n'est pas un gros danger.
Et pourquoi donc faire ça ? Sur Ubuntu qu'on devienne root
en faisant sudo -s ou même su (en ayant mis un mot de passe
au compte root) l'accès à l'affichage - qu'il soit distant
ou local - fonctionne tout seul !
Je programme un daemon (logiciel Tkontrole) qui est lancé au démarrage
de la machine et qui a besoin d'interragir avec l'interface graphique de
n'importe quel utilisateur connecté.
Je ne vois pas trop d'autre méthode pour y parvenir.
Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un utilisateur en faisnat la commande : xhost +LOCAL:
ouch ! C'est pas très bon côté sécurité de jouer avec xhost...
Autoriser l'accès local n'est pas un gros danger.
Et pourquoi donc faire ça ? Sur Ubuntu qu'on devienne root en faisant sudo -s ou même su (en ayant mis un mot de passe au compte root) l'accès à l'affichage - qu'il soit distant ou local - fonctionne tout seul !
Je programme un daemon (logiciel Tkontrole) qui est lancé au démarrage de la machine et qui a besoin d'interragir avec l'interface graphique de n'importe quel utilisateur connecté. Je ne vois pas trop d'autre méthode pour y parvenir.
YBM
Je programme un daemon (logiciel Tkontrole) qui est lancé au démarrage de la machine et qui a besoin d'interragir avec l'interface graphique de n'importe quel utilisateur connecté. Je ne vois pas trop d'autre méthode pour y parvenir.
J'écrirais plutôt une application autonome cliente qui dialoguerait avec le démon (une simple socket UNIX). Tu vas faire comment s'il y a plus d'un utilisateur connecté en local ?
Sinon, regarde plutôt du côté de xauth : soit tu copies le ~/.Xauthority de l'utilisateur connecté dans le répertoire perso de ton démon. soit tu utilise xauth pour lire la liste d'autorisation de l'utilisateur concerné (xauth list) et tu les ajoutes à la liste d'autorisation de ton démon (xauth add).
Je programme un daemon (logiciel Tkontrole) qui est lancé au démarrage
de la machine et qui a besoin d'interragir avec l'interface graphique de
n'importe quel utilisateur connecté.
Je ne vois pas trop d'autre méthode pour y parvenir.
J'écrirais plutôt une application autonome cliente qui dialoguerait
avec le démon (une simple socket UNIX). Tu vas faire comment s'il
y a plus d'un utilisateur connecté en local ?
Sinon, regarde plutôt du côté de xauth :
soit tu copies le ~/.Xauthority de l'utilisateur connecté dans le
répertoire perso de ton démon.
soit tu utilise xauth pour lire la liste d'autorisation de l'utilisateur
concerné (xauth list) et tu les ajoutes à la liste d'autorisation
de ton démon (xauth add).
Je programme un daemon (logiciel Tkontrole) qui est lancé au démarrage de la machine et qui a besoin d'interragir avec l'interface graphique de n'importe quel utilisateur connecté. Je ne vois pas trop d'autre méthode pour y parvenir.
J'écrirais plutôt une application autonome cliente qui dialoguerait avec le démon (une simple socket UNIX). Tu vas faire comment s'il y a plus d'un utilisateur connecté en local ?
Sinon, regarde plutôt du côté de xauth : soit tu copies le ~/.Xauthority de l'utilisateur connecté dans le répertoire perso de ton démon. soit tu utilise xauth pour lire la liste d'autorisation de l'utilisateur concerné (xauth list) et tu les ajoutes à la liste d'autorisation de ton démon (xauth add).
Thierry B.
--{ YBM a plopé ceci: }--
Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un utilisateur en faisnat la commande : xhost +LOCAL:
ouch ! C'est pas très bon côté sécurité de jouer avec xhost...
Je pense même que c'est fortement déconseillé dans le groupe fr.comp.applications.x11 qui est bien mieux approprié que fco.LINUX.configuration pour ce genre de problème.
Et je ne met même pas de foutou, parce que ça ne sert à rien.
-- fsp est un boxon innommable: un stalinien n'y retrouvera pas son goulag. --{ BP, in fm.divers }--
--{ YBM a plopé ceci: }--
Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un
utilisateur en faisnat la commande :
xhost +LOCAL:
ouch ! C'est pas très bon côté sécurité de jouer avec xhost...
Je pense même que c'est fortement déconseillé dans le groupe
fr.comp.applications.x11 qui est bien mieux approprié que
fco.LINUX.configuration pour ce genre de problème.
Et je ne met même pas de foutou, parce que ça ne sert à rien.
--
fsp est un boxon innommable: un stalinien n'y retrouvera pas son goulag.
--{ BP, in fm.divers }--
Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un utilisateur en faisnat la commande : xhost +LOCAL:
ouch ! C'est pas très bon côté sécurité de jouer avec xhost...
Je pense même que c'est fortement déconseillé dans le groupe fr.comp.applications.x11 qui est bien mieux approprié que fco.LINUX.configuration pour ce genre de problème.
Et je ne met même pas de foutou, parce que ça ne sert à rien.
-- fsp est un boxon innommable: un stalinien n'y retrouvera pas son goulag. --{ BP, in fm.divers }--
vincent.verdon
Bonsoir,
--{ YBM a plopé ceci: }--
Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un utilisateur en faisnat la commande : xhost +LOCAL: ouch ! C'est pas très bon côté sécurité de jouer avec xhost...
Je pense même que c'est fortement déconseillé dans le groupe fr.comp.applications.x11 qui est bien mieux approprié que fco.LINUX.configuration pour ce genre de problème.
Sauf que je pense qu'il s'agit d'un bug de Linux, il me semble que sous d'autres Unix cela fonctionne d'après ce que j'ai pu trouver comme infos.
Et je ne met même pas de foutou, parce que ça ne sert à rien.
Je ne comprends pas bien le sens de cette remarque... qui ne me semble
pas bien aimable...
Cordialement, Vincent Verdon
Bonsoir,
--{ YBM a plopé ceci: }--
Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un
utilisateur en faisnat la commande :
xhost +LOCAL:
ouch ! C'est pas très bon côté sécurité de jouer avec xhost...
Je pense même que c'est fortement déconseillé dans le groupe
fr.comp.applications.x11 qui est bien mieux approprié que
fco.LINUX.configuration pour ce genre de problème.
Sauf que je pense qu'il s'agit d'un bug de Linux, il me semble que sous
d'autres Unix cela fonctionne d'après ce que j'ai pu trouver comme infos.
Et je ne met même pas de foutou, parce que ça ne sert à rien.
Je ne comprends pas bien le sens de cette remarque... qui ne me semble
Sur Ubuntu, je peux autoriser root à utiliser le Xwindow d'un utilisateur en faisnat la commande : xhost +LOCAL: ouch ! C'est pas très bon côté sécurité de jouer avec xhost...
Je pense même que c'est fortement déconseillé dans le groupe fr.comp.applications.x11 qui est bien mieux approprié que fco.LINUX.configuration pour ce genre de problème.
Sauf que je pense qu'il s'agit d'un bug de Linux, il me semble que sous d'autres Unix cela fonctionne d'après ce que j'ai pu trouver comme infos.
Et je ne met même pas de foutou, parce que ça ne sert à rien.
Je ne comprends pas bien le sens de cette remarque... qui ne me semble
pas bien aimable...
Cordialement, Vincent Verdon
YBM
Sauf que je pense qu'il s'agit d'un bug de Linux, il me semble que sous d'autres Unix cela fonctionne d'après ce que j'ai pu trouver comme infos.
Linux n'est qu'un noyau, un détail aussi fin du comportement de X11 ne peut provenir d'un bug du noyau. De fait c'est un choix (et c'est, amha, un bon choix) des distributions d'avoir rendu impossibles les bidouilles à coup de xhost.
Sauf que je pense qu'il s'agit d'un bug de Linux, il me semble que sous
d'autres Unix cela fonctionne d'après ce que j'ai pu trouver comme infos.
Linux n'est qu'un noyau, un détail aussi fin du comportement de X11 ne
peut provenir d'un bug du noyau. De fait c'est un choix (et c'est, amha,
un bon choix) des distributions d'avoir rendu impossibles les bidouilles
à coup de xhost.
Sauf que je pense qu'il s'agit d'un bug de Linux, il me semble que sous d'autres Unix cela fonctionne d'après ce que j'ai pu trouver comme infos.
Linux n'est qu'un noyau, un détail aussi fin du comportement de X11 ne peut provenir d'un bug du noyau. De fait c'est un choix (et c'est, amha, un bon choix) des distributions d'avoir rendu impossibles les bidouilles à coup de xhost.
vincent.verdon
Bonjour,
Sauf que je pense qu'il s'agit d'un bug de Linux, il me semble que sous d'autres Unix cela fonctionne d'après ce que j'ai pu trouver comme infos.
Linux n'est qu'un noyau, un détail aussi fin du comportement de X11 ne peut provenir d'un bug du noyau. De fait c'est un choix (et c'est, amha, un bon choix) des distributions d'avoir rendu impossibles les bidouilles à coup de xhost.
Les "bidouilles" sont possibles ! Je peux parfaitement faire xhost + par exemple (ça c'est une vrai horreur, j'en conviens !), mais je ne peux pas utiliser X0.hosts pour configurer xhost, voila tout.
Maintenant, il s'agit certainement d'un pb de Xorg plus que du noyau, effectivement.
Amicalement, Vincent Verdon
Bonjour,
Sauf que je pense qu'il s'agit d'un bug de Linux, il me semble que
sous d'autres Unix cela fonctionne d'après ce que j'ai pu trouver
comme infos.
Linux n'est qu'un noyau, un détail aussi fin du comportement de X11 ne
peut provenir d'un bug du noyau. De fait c'est un choix (et c'est, amha,
un bon choix) des distributions d'avoir rendu impossibles les bidouilles
à coup de xhost.
Les "bidouilles" sont possibles ! Je peux parfaitement faire xhost + par
exemple (ça c'est une vrai horreur, j'en conviens !), mais je ne peux
pas utiliser X0.hosts pour configurer xhost, voila tout.
Maintenant, il s'agit certainement d'un pb de Xorg plus que du noyau,
effectivement.
Sauf que je pense qu'il s'agit d'un bug de Linux, il me semble que sous d'autres Unix cela fonctionne d'après ce que j'ai pu trouver comme infos.
Linux n'est qu'un noyau, un détail aussi fin du comportement de X11 ne peut provenir d'un bug du noyau. De fait c'est un choix (et c'est, amha, un bon choix) des distributions d'avoir rendu impossibles les bidouilles à coup de xhost.
Les "bidouilles" sont possibles ! Je peux parfaitement faire xhost + par exemple (ça c'est une vrai horreur, j'en conviens !), mais je ne peux pas utiliser X0.hosts pour configurer xhost, voila tout.
Maintenant, il s'agit certainement d'un pb de Xorg plus que du noyau, effectivement.
Amicalement, Vincent Verdon
YBM
Maintenant, il s'agit certainement d'un pb de Xorg plus que du noyau, effectivement.
Tu as essayé avec xauth ?
Maintenant, il s'agit certainement d'un pb de Xorg plus que du noyau,
effectivement.
Maintenant, il s'agit certainement d'un pb de Xorg plus que du noyau, effectivement.
Tu as essayé avec xauth ?
vincent.verdon
Bonjour,
Maintenant, il s'agit certainement d'un pb de Xorg plus que du noyau, effectivement.
Tu as essayé avec xauth ?
Je viens d'essayer, il est très simple d'accéder à Xwindow d'une personne toto en faisant depuis une console : export XAUTHORITY=/home/toto/.Xauthority
Mais je ne sais pas accéder à Xwindow si aucune personne n'est connectée et que c'est gdm (ou autre) qui a la main.
Cordialement, Vincent Verdon
Bonjour,
Maintenant, il s'agit certainement d'un pb de Xorg plus que du noyau,
effectivement.
Tu as essayé avec xauth ?
Je viens d'essayer, il est très simple d'accéder à Xwindow d'une
personne toto en faisant depuis une console :
export XAUTHORITY=/home/toto/.Xauthority
Mais je ne sais pas accéder à Xwindow si aucune personne n'est connectée
et que c'est gdm (ou autre) qui a la main.
Maintenant, il s'agit certainement d'un pb de Xorg plus que du noyau, effectivement.
Tu as essayé avec xauth ?
Je viens d'essayer, il est très simple d'accéder à Xwindow d'une personne toto en faisant depuis une console : export XAUTHORITY=/home/toto/.Xauthority
Mais je ne sais pas accéder à Xwindow si aucune personne n'est connectée et que c'est gdm (ou autre) qui a la main.
Cordialement, Vincent Verdon
vincent.verdon
Bonjour,
Je programme un daemon (logiciel Tkontrole) qui est lancé au démarrage de la machine et qui a besoin d'interragir avec l'interface graphique de n'importe quel utilisateur connecté. Je ne vois pas trop d'autre méthode pour y parvenir.
J'écrirais plutôt une application autonome cliente qui dialoguerait avec le démon (une simple socket UNIX). Tu vas faire comment s'il y a plus d'un utilisateur connecté en local ?
C'est assez peu fréquent que plusieurs utilisateurs utilisent une connexion en graphique sur une même machine.
le pb de faire exécuter une application côté utilisateur c'est que l'utilisateur peut la tuer, ce que je ne veux pas. c'est d'ailleurs un pb que je rencontre pour le développement de la même appli sous Vista actuellement... Sauf que sous Vista, il n'y a ni xhost ni xauth.
Cordialement, Vincent Verdon
Bonjour,
Je programme un daemon (logiciel Tkontrole) qui est lancé au démarrage
de la machine et qui a besoin d'interragir avec l'interface graphique
de n'importe quel utilisateur connecté.
Je ne vois pas trop d'autre méthode pour y parvenir.
J'écrirais plutôt une application autonome cliente qui dialoguerait
avec le démon (une simple socket UNIX). Tu vas faire comment s'il
y a plus d'un utilisateur connecté en local ?
C'est assez peu fréquent que plusieurs utilisateurs utilisent une
connexion en graphique sur une même machine.
le pb de faire exécuter une application côté utilisateur c'est que
l'utilisateur peut la tuer, ce que je ne veux pas. c'est d'ailleurs un
pb que je rencontre pour le développement de la même appli sous Vista
actuellement... Sauf que sous Vista, il n'y a ni xhost ni xauth.
Je programme un daemon (logiciel Tkontrole) qui est lancé au démarrage de la machine et qui a besoin d'interragir avec l'interface graphique de n'importe quel utilisateur connecté. Je ne vois pas trop d'autre méthode pour y parvenir.
J'écrirais plutôt une application autonome cliente qui dialoguerait avec le démon (une simple socket UNIX). Tu vas faire comment s'il y a plus d'un utilisateur connecté en local ?
C'est assez peu fréquent que plusieurs utilisateurs utilisent une connexion en graphique sur une même machine.
le pb de faire exécuter une application côté utilisateur c'est que l'utilisateur peut la tuer, ce que je ne veux pas. c'est d'ailleurs un pb que je rencontre pour le développement de la même appli sous Vista actuellement... Sauf que sous Vista, il n'y a ni xhost ni xauth.
