XDMCP PolicyKit PAM ConsoleKit

Le
Joe the Shmoe
Bonjour,

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 ?

Merci pour toute aide.
Joe.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Lucas Levrel
Le #24498881
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
Joe the Shmoe
Le #24499581
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).



Oui, consoleKit tourne effectivement :

#ps -ef | grep onsole
root 20232 1 0 May20 ? 00:00:01
/usr/sbin/console-kit-daemon --no-daemon


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:

#ck-list-sessions
Session45:
unix-user = '1002'
realname = 'xxxx'
seat = 'Seat11'
session-type = 'gdm'
active = FALSE
x11-display = '192.168.5.2:1'
x11-display-device = ''
display-device = ''
remote-host-name = '192.168.5.2'
is-local = FALSE
on-since = '2012-05-23T06:15:45.924220Z'
login-session-id = ''
Session44:
unix-user = '1000'
realname = 'yyyyy'
seat = 'Seat1'
session-type = 'gdm'
active = TRUE
x11-display = ':9'
x11-display-device = '/dev/tty7'
display-device = ''
remote-host-name = ''
is-local = TRUE
on-since = '2012-05-23T06:13:09.394570Z'
login-session-id = ''

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 #24515131
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

/usr/share/polkit-1/actions/org.freedesktop.udisks.policy

(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
Le #24536301
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:

/usr/share/polkit-1/actions/org.freedesktop.udisks.policy

pour les actions de montage/démontage:

<allow_any>yes</allow_any>

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 (dmask77) 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.
Publicité
Poster une réponse
Anonyme