Depuis un PC configuré en terminal X, j'accède via le réseau à un autre
PC en XDMCP, là pas de souci. Cependant, une fois loggué via XDMCP, je
ne peux pas accéder à bon nombre de matériel, tel le scanner, et les
clefs USB (pas de souci pour l'imprimante via cups), auxquels j'accède
normalement quand je suis loggué sous le même compte depuis le PC lui-même.
Après quelque recherches, j'ai l'impression que c'est un problème de
configuration de ConsoleKit (?) mais faute d'une documentation assez
détaillée je n'ai pas réussi à trouver une configuration qui fonctionne.
Est-ce que quelqu'un a une idée du problème ? Est-ce bien ConsoleKit et
non Policykit ou PAM qu'il faut modifier ?
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
Lucas Levrel
Le 22 mai 2012, Joe the Shmoe a écrit :
Après quelque recherches, j'ai l'impression que c'est un problème de configuration de ConsoleKit (?) mais faute d'une documentation assez détaillée je n'ai pas réussi à trouver une configuration qui fonctionne.
Est-ce que quelqu'un a une idée du problème ? Est-ce bien ConsoleKit et non Policykit ou PAM qu'il faut modifier ?
Est-ce que CK tourne effectivement une fois que tu es connecté ? J'éplucherais la sortie de "ps -e" à la recherche de ck-quelquechose (j'ignore le nom exact du processus).
Sinon, il faut le lancer au démarrage de la session X. Dans mon .xinitrc j'ai remplacé : exec $WINDOWMANAGER ;; par : exec /usr/bin/ck-launch-session $WINDOWMANAGER ;;
-- LL
Le 22 mai 2012, Joe the Shmoe a écrit :
Après quelque recherches, j'ai l'impression que c'est un problème de
configuration de ConsoleKit (?) mais faute d'une documentation assez
détaillée je n'ai pas réussi à trouver une configuration qui fonctionne.
Est-ce que quelqu'un a une idée du problème ? Est-ce bien ConsoleKit et
non Policykit ou PAM qu'il faut modifier ?
Est-ce que CK tourne effectivement une fois que tu es connecté ?
J'éplucherais la sortie de "ps -e" à la recherche de ck-quelquechose
(j'ignore le nom exact du processus).
Sinon, il faut le lancer au démarrage de la session X. Dans mon .xinitrc
j'ai remplacé :
exec $WINDOWMANAGER ;;
par :
exec /usr/bin/ck-launch-session $WINDOWMANAGER ;;
Après quelque recherches, j'ai l'impression que c'est un problème de configuration de ConsoleKit (?) mais faute d'une documentation assez détaillée je n'ai pas réussi à trouver une configuration qui fonctionne.
Est-ce que quelqu'un a une idée du problème ? Est-ce bien ConsoleKit et non Policykit ou PAM qu'il faut modifier ?
Est-ce que CK tourne effectivement une fois que tu es connecté ? J'éplucherais la sortie de "ps -e" à la recherche de ck-quelquechose (j'ignore le nom exact du processus).
Sinon, il faut le lancer au démarrage de la session X. Dans mon .xinitrc j'ai remplacé : exec $WINDOWMANAGER ;; par : exec /usr/bin/ck-launch-session $WINDOWMANAGER ;;
-- LL
Joe the Shmoe
Le 22/05/2012 21:50, Lucas Levrel a écrit :
Le 22 mai 2012, Joe the Shmoe a écrit :
Est-ce que quelqu'un a une idée du problème ? Est-ce bien ConsoleKit et non Policykit ou PAM qu'il faut modifier ?
Est-ce que CK tourne effectivement une fois que tu es connecté ? J'éplucherais la sortie de "ps -e" à la recherche de ck-quelquechose (j'ignore le nom exact du processus).
Sinon, il faut le lancer au démarrage de la session X. Dans mon .xinitrc j'ai remplacé : exec $WINDOWMANAGER ;; par : exec /usr/bin/ck-launch-session $WINDOWMANAGER ;;
je ne connaissais pas les commandes ck-... (et pas de page de man pour expliquer) mais ck-list-sessions est intéressant même si ça ne résout pas mon problème:
J'ai bien deux sessions, l'une sur le poste qui est locale (is-local TRUE), l'autre via XDMCP (is-local = FALSE).
J'avais cherché au début à modifier gdm3 afin qu'il considère comme locale les sessions en provenance de 192.168.5.2 mais apparemment c'est codé en dur (?) en tous les cas là non plus aucune documentation trouvée sur une éventuelle option à positionner dans son fichier de configuration...
J'ai bien l'impression que c'est console-kit par le fait que la session n'est pas locale qui interdit l'accès à certains matériels, mais je n'ai pas trouvé comment modifier son comportement... ni même où c'était défini.
Merci pour ta réponse.
Cordialement, Joe.
Le 22/05/2012 21:50, Lucas Levrel a écrit :
Le 22 mai 2012, Joe the Shmoe a écrit :
Est-ce que quelqu'un a une idée du problème ? Est-ce bien ConsoleKit et
non Policykit ou PAM qu'il faut modifier ?
Est-ce que CK tourne effectivement une fois que tu es connecté ?
J'éplucherais la sortie de "ps -e" à la recherche de ck-quelquechose
(j'ignore le nom exact du processus).
Sinon, il faut le lancer au démarrage de la session X. Dans mon .xinitrc
j'ai remplacé :
exec $WINDOWMANAGER ;;
par :
exec /usr/bin/ck-launch-session $WINDOWMANAGER ;;
je ne connaissais pas les commandes ck-... (et pas de page de man pour
expliquer) mais ck-list-sessions est intéressant même si ça ne résout
pas mon problème:
J'ai bien deux sessions, l'une sur le poste qui est locale (is-local TRUE), l'autre via XDMCP (is-local = FALSE).
J'avais cherché au début à modifier gdm3 afin qu'il considère comme
locale les sessions en provenance de 192.168.5.2 mais apparemment c'est
codé en dur (?) en tous les cas là non plus aucune documentation trouvée
sur une éventuelle option à positionner dans son fichier de configuration...
J'ai bien l'impression que c'est console-kit par le fait que la session
n'est pas locale qui interdit l'accès à certains matériels, mais je n'ai
pas trouvé comment modifier son comportement... ni même où c'était défini.
Est-ce que quelqu'un a une idée du problème ? Est-ce bien ConsoleKit et non Policykit ou PAM qu'il faut modifier ?
Est-ce que CK tourne effectivement une fois que tu es connecté ? J'éplucherais la sortie de "ps -e" à la recherche de ck-quelquechose (j'ignore le nom exact du processus).
Sinon, il faut le lancer au démarrage de la session X. Dans mon .xinitrc j'ai remplacé : exec $WINDOWMANAGER ;; par : exec /usr/bin/ck-launch-session $WINDOWMANAGER ;;
je ne connaissais pas les commandes ck-... (et pas de page de man pour expliquer) mais ck-list-sessions est intéressant même si ça ne résout pas mon problème:
J'ai bien deux sessions, l'une sur le poste qui est locale (is-local TRUE), l'autre via XDMCP (is-local = FALSE).
J'avais cherché au début à modifier gdm3 afin qu'il considère comme locale les sessions en provenance de 192.168.5.2 mais apparemment c'est codé en dur (?) en tous les cas là non plus aucune documentation trouvée sur une éventuelle option à positionner dans son fichier de configuration...
J'ai bien l'impression que c'est console-kit par le fait que la session n'est pas locale qui interdit l'accès à certains matériels, mais je n'ai pas trouvé comment modifier son comportement... ni même où c'était défini.
Merci pour ta réponse.
Cordialement, Joe.
Joe the Shmoe
Le 22/05/2012 21:50, Lucas Levrel a écrit :
Le 22 mai 2012, Joe the Shmoe a écrit :
Après quelque recherches, j'ai l'impression que c'est un problème de configuration de ConsoleKit (?) mais faute d'une documentation assez détaillée je n'ai pas réussi à trouver une configuration qui fonctionne.
Est-ce que quelqu'un a une idée du problème ? Est-ce bien ConsoleKit et non Policykit ou PAM qu'il faut modifier ?
Est-ce que CK tourne effectivement une fois que tu es connecté ? J'éplucherais la sortie de "ps -e" à la recherche de ck-quelquechose (j'ignore le nom exact du processus).
Sinon, il faut le lancer au démarrage de la session X. Dans mon .xinitrc j'ai remplacé : exec $WINDOWMANAGER ;; par : exec /usr/bin/ck-launch-session $WINDOWMANAGER ;;
Quelques avancées:
d'après ce que j'ai compris lors de l'authentification via XDMCP, PAM est utilisé et lance consolkit
sous Debian c'est la ligne suivante dans le fichier /etc/pam.d/common-sessions : session optional pam_ck_connector.so nox11
consolkit assigne un siège "local" si on se loggue directement sur la machine et "non local" si on se loggue via XDMCP (je n'ai pas trouvé le moyen d'influer là dessus). [voir la commande "ck-list-sessions"]
Ensuite d'un autre côté, c'est policykit qui définit les autorisations pour les différents types d'utilisateurs. Il m'a fallut modifier
(ce n'est pas très heureux, car lors d'une mise à jour du paquet je perdrait les modifications ... :-( tout conseil bienvenu).
et dans ce fichier XML mettre "yes" aux <allow_any> pour les actions de montage, démontage, etc.
Depuis je peux maintenant monter/demonter et lire un CD lorsque j'accède à la machine via XDMCP.
Pour les clefs USB, c'est un peu différent, car le noyau signal à udev la présence d'un nouveau périphérique, qui sollicite udisk à son tour. Celui-ci monte automatiquement le disque en dehors de toute référence à une session ... en fait non, il prend l'utilisateur du premier siège qu'il trouve et assigne au système de fichier (si type vfat) son propriétaire avec une permission qui n'autorise que lui à lire la clef.
Donc, pour des questions de permission, si je ne suis pas le seul en XDMCP, je n'ai pas le droit de lire la clef USB.
conclusion, reste à trouver comment modifier l'attribut "dmask" que udisk place lorsqu'il monte le volume vfat ... je n'ai pas encore trouvé comment... tout aide bienvenue.
a+ Joe.
Le 22/05/2012 21:50, Lucas Levrel a écrit :
Le 22 mai 2012, Joe the Shmoe a écrit :
Après quelque recherches, j'ai l'impression que c'est un problème de
configuration de ConsoleKit (?) mais faute d'une documentation assez
détaillée je n'ai pas réussi à trouver une configuration qui fonctionne.
Est-ce que quelqu'un a une idée du problème ? Est-ce bien ConsoleKit et
non Policykit ou PAM qu'il faut modifier ?
Est-ce que CK tourne effectivement une fois que tu es connecté ?
J'éplucherais la sortie de "ps -e" à la recherche de ck-quelquechose
(j'ignore le nom exact du processus).
Sinon, il faut le lancer au démarrage de la session X. Dans mon .xinitrc
j'ai remplacé :
exec $WINDOWMANAGER ;;
par :
exec /usr/bin/ck-launch-session $WINDOWMANAGER ;;
Quelques avancées:
d'après ce que j'ai compris lors de l'authentification via XDMCP, PAM
est utilisé et lance consolkit
sous Debian c'est la ligne suivante dans le fichier
/etc/pam.d/common-sessions :
session optional pam_ck_connector.so nox11
consolkit assigne un siège "local" si on se loggue directement sur la
machine et "non local" si on se loggue via XDMCP (je n'ai pas trouvé le
moyen d'influer là dessus). [voir la commande "ck-list-sessions"]
Ensuite d'un autre côté, c'est policykit qui définit les autorisations
pour les différents types d'utilisateurs. Il m'a fallut modifier
(ce n'est pas très heureux, car lors d'une mise à jour du paquet je
perdrait les modifications ... :-( tout conseil bienvenu).
et dans ce fichier XML mettre "yes" aux <allow_any> pour les actions de
montage, démontage, etc.
Depuis je peux maintenant monter/demonter et lire un CD lorsque j'accède
à la machine via XDMCP.
Pour les clefs USB, c'est un peu différent, car le noyau signal à udev
la présence d'un nouveau périphérique, qui sollicite udisk à son tour.
Celui-ci monte automatiquement le disque en dehors de toute référence à
une session ... en fait non, il prend l'utilisateur du premier siège
qu'il trouve et assigne au système de fichier (si type vfat) son
propriétaire avec une permission qui n'autorise que lui à lire la clef.
Donc, pour des questions de permission, si je ne suis pas le seul en
XDMCP, je n'ai pas le droit de lire la clef USB.
conclusion, reste à trouver comment modifier l'attribut "dmask" que
udisk place lorsqu'il monte le volume vfat ... je n'ai pas encore trouvé
comment... tout aide bienvenue.
Après quelque recherches, j'ai l'impression que c'est un problème de configuration de ConsoleKit (?) mais faute d'une documentation assez détaillée je n'ai pas réussi à trouver une configuration qui fonctionne.
Est-ce que quelqu'un a une idée du problème ? Est-ce bien ConsoleKit et non Policykit ou PAM qu'il faut modifier ?
Est-ce que CK tourne effectivement une fois que tu es connecté ? J'éplucherais la sortie de "ps -e" à la recherche de ck-quelquechose (j'ignore le nom exact du processus).
Sinon, il faut le lancer au démarrage de la session X. Dans mon .xinitrc j'ai remplacé : exec $WINDOWMANAGER ;; par : exec /usr/bin/ck-launch-session $WINDOWMANAGER ;;
Quelques avancées:
d'après ce que j'ai compris lors de l'authentification via XDMCP, PAM est utilisé et lance consolkit
sous Debian c'est la ligne suivante dans le fichier /etc/pam.d/common-sessions : session optional pam_ck_connector.so nox11
consolkit assigne un siège "local" si on se loggue directement sur la machine et "non local" si on se loggue via XDMCP (je n'ai pas trouvé le moyen d'influer là dessus). [voir la commande "ck-list-sessions"]
Ensuite d'un autre côté, c'est policykit qui définit les autorisations pour les différents types d'utilisateurs. Il m'a fallut modifier
(ce n'est pas très heureux, car lors d'une mise à jour du paquet je perdrait les modifications ... :-( tout conseil bienvenu).
et dans ce fichier XML mettre "yes" aux <allow_any> pour les actions de montage, démontage, etc.
Depuis je peux maintenant monter/demonter et lire un CD lorsque j'accède à la machine via XDMCP.
Pour les clefs USB, c'est un peu différent, car le noyau signal à udev la présence d'un nouveau périphérique, qui sollicite udisk à son tour. Celui-ci monte automatiquement le disque en dehors de toute référence à une session ... en fait non, il prend l'utilisateur du premier siège qu'il trouve et assigne au système de fichier (si type vfat) son propriétaire avec une permission qui n'autorise que lui à lire la clef.
Donc, pour des questions de permission, si je ne suis pas le seul en XDMCP, je n'ai pas le droit de lire la clef USB.
conclusion, reste à trouver comment modifier l'attribut "dmask" que udisk place lorsqu'il monte le volume vfat ... je n'ai pas encore trouvé comment... tout aide bienvenue.
a+ Joe.
Joe the Shmoe
Pour référence:
sur un PC multi siège (multi-seat) proposant des accès en local et via XDMCP, une clef USB n'est accessible par défaut (sous Debian) que par un siège local. Pour permettre l'accès aux utilisateurs connectés en XDMCP, il faut d'abord modifier la configuration policy-kit de udisks:
Comme les clefs USB sont en générale formatées en vfat, le propriétaire des fichiers de la clef est alors le premier utilisateur à avoir monté la clef... pas très pratique. La seule façon que j'ai trouvé de modifier les options passée à mount (dmask 77) est de modifier udisks et le recompiler car ces options sont codée en dur dans le program !!! (fichier device.c)
Après ça, ça marche nickel, une clef USB est accessible par tous les utilisateurs loggés que ce soit en local ou en XDMCP.
Joe.
P.S.: XDMCP n'est pas un protocole sécurisé, son utilisation native est raisonnable sur un LAN domestique protégé par un firewall. Pour un accès via Internet on utilisera tout méthode nécessaire pour chiffrer les données tel un VPN IPSec par exemple.
Pour référence:
sur un PC multi siège (multi-seat) proposant des accès en local et via
XDMCP, une clef USB n'est accessible par défaut (sous Debian) que par un
siège local. Pour permettre l'accès aux utilisateurs connectés en XDMCP,
il faut d'abord modifier la configuration policy-kit de udisks:
Comme les clefs USB sont en générale formatées en vfat, le propriétaire
des fichiers de la clef est alors le premier utilisateur à avoir monté
la clef... pas très pratique. La seule façon que j'ai trouvé de modifier
les options passée à mount (dmask 77) est de modifier udisks et le
recompiler car ces options sont codée en dur dans le program !!!
(fichier device.c)
Après ça, ça marche nickel, une clef USB est accessible par tous les
utilisateurs loggés que ce soit en local ou en XDMCP.
Joe.
P.S.: XDMCP n'est pas un protocole sécurisé, son utilisation native est
raisonnable sur un LAN domestique protégé par un firewall. Pour un accès
via Internet on utilisera tout méthode nécessaire pour chiffrer les
données tel un VPN IPSec par exemple.
sur un PC multi siège (multi-seat) proposant des accès en local et via XDMCP, une clef USB n'est accessible par défaut (sous Debian) que par un siège local. Pour permettre l'accès aux utilisateurs connectés en XDMCP, il faut d'abord modifier la configuration policy-kit de udisks:
Comme les clefs USB sont en générale formatées en vfat, le propriétaire des fichiers de la clef est alors le premier utilisateur à avoir monté la clef... pas très pratique. La seule façon que j'ai trouvé de modifier les options passée à mount (dmask 77) est de modifier udisks et le recompiler car ces options sont codée en dur dans le program !!! (fichier device.c)
Après ça, ça marche nickel, une clef USB est accessible par tous les utilisateurs loggés que ce soit en local ou en XDMCP.
Joe.
P.S.: XDMCP n'est pas un protocole sécurisé, son utilisation native est raisonnable sur un LAN domestique protégé par un firewall. Pour un accès via Internet on utilisera tout méthode nécessaire pour chiffrer les données tel un VPN IPSec par exemple.
