Scanner LiDE20 détecté par sane avec root uniquement
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Reprise du message précédent
Bonjour,Que donne la commande getfacl sur le fichier de scanner ?
edit: je pense qu' il serait plus pertinent de faire le strace sur le scanimage plutôt que sur le sane-find-scanner.
Édité par nic80 Le 15/03/2026 à 12h27
Rick399 Membre non connecté
-
- Voir le profil du membre Rick399
- Inscrit le : 13/03/2026
- Groupes :
nic80 :Que donne la commande getfacl sur le fichier de scanner ?
On parle bien de l'emplacement sur lequel est connecté le scanner ?
Si oui :
Code BASH :
qui donne :getfacl /dev/bus/usb/001/011
Code :
getfacl : suppression du premier « / » des noms de chemins absolus
# file: dev/bus/usb/001/011
# owner: root
# group: scanner
user::rw-
user:monuser:rw-
group::rw-
group:lp:rw-
mask::rw-
other::r--
nic80 :je pense qu' il serait plus pertinent de faire le strace sur le scanimage plutôt que sur le sane-find-scanner
J'ai utilisé les commandes suivantes :
Code BASH :
strace -e open,read,write scanimage -L 2>strace-scanimageL.txt sudo strace -e open,read,write scanimage -L 2>strace-scanimageL-sudo.txt diff -1 -3 strace-scanimageL.txt strace-scanimageL-sudo.txt > diff-strace-scanimageL.txt
Le scanimage en utilisateur simple : strace-scanimageL.txt
Le scanimage en mode root : strace-scanimageL-sudo.txt
La différence : diff-strace-scanimageL.txt
J'avoue que je ne sais pas trop comment interpréter ces fichiers.
J'ai essayé de comparer.
Dans le fichier strace-scanimage-sudo.txt on retrouve bien "plustek" qui est absent de la trace standard. Et on voit qu'à la fin de la trace avec root il inscrit le périphérique plustek:libusb:001:011.
Mais je ne sais pas trop ce que je devrais chercher.
Dans le doute j'ai essayé une trace pour simuler un scan également.
Le scanimage en utilisateur simple : strace-scanimageT.txt
Le scanimage en mode root : strace-scanimageT-sudo.txt
La différence : diff-strace-scanimageT.txt
Les différences son très proches de la comparaison précédente.
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Je dirais qu' en terme de droits cela devrait être bon ( monuser a bien des droits lecture/écriture).
Dans la sortie, j' ai l' impression que l' on filtre la sortie de strace sur quelques évenements -open,read,write - et on ne redirige que certains élements vers le fichier ( si la cause n' est pas dans ces évenements on ne verra rien). Je verrais plus un strace -o strace-scanimage-complet.txt scanimage -L ( en utilisateur normal ( il sera déjà assez indigeste
)
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
nic80 :Bonjour,
Je dirais qu' en terme de droits cela devrait être bon ( monuser a bien des droits lecture/écriture).
Dans la sortie, j' ai l' impression que l' on filtre la sortie de strace sur quelques évenements -open,read,write - et on ne redirige que certains élements vers le fichier ( si la cause n' est pas dans ces évenements on ne verra rien). Je verrais plus un strace -o strace-scanimage-complet.txt scanimage -L ( en utilisateur normal ( il sera déjà assez indigeste
Juste, le filtre est certainement trop sélectif.
Avant de supprimer le filtre, il pourrait être intéressant de remplacer open par openat.
Rick399 Membre non connecté
-
- Voir le profil du membre Rick399
- Inscrit le : 13/03/2026
- Groupes :
Merci pour vos retours.
J'ai exécuté la commande à nouveau avec openat et cela permet d'avoir un peu plus d'infos !
Lorsqu'on arrive au scanner il le trouve mais à un souci de droits :
Code :
openat(AT_FDCWD, "/usr/lib64/sane/libsane-plustek.so.1", O_RDONLY) = 7
openat(AT_FDCWD, "/usr/lib64/sane/libsane-plustek.so.1", O_RDONLY|O_CLOEXEC) = 7
read(7, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
openat(AT_FDCWD, "/dev/bus/usb/004/001", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD, "/dev/bus/usb/003/001", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD, "/dev/bus/usb/002/001", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD, "/dev/bus/usb/001/006", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD, "/dev/bus/usb/001/005", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD, "/dev/bus/usb/001/003", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD, "/dev/bus/usb/001/004", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD, "/dev/bus/usb/001/002", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD, "/dev/bus/usb/001/007", O_RDWR|O_CLOEXEC) = 7
openat(AT_FDCWD, "/sys/bus/usb/devices/1-10/bConfigurationValue", O_RDONLY|O_CLOEXEC) = 8
read(8, "1\n", 19) = 2
openat(AT_FDCWD, "/dev/bus/usb/001/001", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD, "./plustek.conf", O_RDONLY) = -1 ENOENT (Aucun fichier ou dossier de ce nom)
openat(AT_FDCWD, "/etc/sane.d/plustek.conf", O_RDONLY) = 7
read(7, "# Plustek-SANE Backend configura"..., 4096) = 4096
read(7, "r\ndevice auto\n\n#\n# to define a n"..., 4096) = 113
read(7, "", 4096) = 0
openat(AT_FDCWD, "/var/lock/LCK..libusb:001:007", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EACCES (Permission non accordée)
Par contre l'utilisateur arrive bien à accéder à /dev/bus/usb/001/007 sans problème.
Je n'aurai pas le temps ce soir mais dans la semaine ou ce weekend je vais revérifier les droits et re-comparer avec Mageia 9, j'ai dû passer à côté de quelque chose.
je vous tiens au courant.
Ci joint les fichiers :
Scanimage mode utilisateur : strace-scanimageL-openat.txt
Scanimage mode root : strace-scanimageL-openat-sudo.txt
La différence : diff-strace-scanimageL-openat.txt
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
J'aurais du conseiller find /dev >…
Je reste certain qu'il faut jouer avec udev
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Effectivement, ce post ci semble indiquer une règle udev mais aussi un droit sur le répertoire /var/lock/sane.
https://bbs.archlinux.org/viewtopic.php?id=47396
Ici en tant qu'utilisateur normal on a un refus d' accès à /var/lock/quelquechose.
Du coup est ce qu' il faudrait créer le fichier /var/lock/sane en lui mettant les droits groupe scanner en lecture/écriture ?
Édité par nic80 Le 17/03/2026 à 07h47
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
Ceci m'interpelle
Code TEXT :
openat(AT_FDCWD, "/var/lock/LCK..libusb:001:007", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EACCES (Permission non accordée)
Ceci ressemble à une tentative de création d'un verrou qui échoue en utilisateur simple.
Soit l'utilisateur n'a pas les droits d'écriture dans le répertoire, soit le verrou existe déjà.
/var/lock est renvoyé vers /run/lock par des liens symboliques sur Mageia 9
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Je penche pour la première hypothèse. Ç' est d' aileurs ce refus qui m' a amené à la page Archlinux.
Édité par nic80 Le 17/03/2026 à 10h21
Rick399 Membre non connecté
-
- Voir le profil du membre Rick399
- Inscrit le : 13/03/2026
- Groupes :
Merci pour tous vos retours.
Jybz :Désolé, mes commandes avec ls et diff ne sont pas superbes.
Toute information est bonne à prendre, puis j'apprends de nouvelles commandes
nic80 :Du coup est ce qu' il faudrait créer le fichier /var/lock/sane en lui mettant les droits groupe scanner en lecture/écriture ?
J'étais tombé sur un fichier un peu similaire mais dans /var/lib/lock pour Mageia. C'est un des écarts constatés, après modification des droits pour qu'ils correspondent à Mageia 9 cela n'avait rien changé.
Papoteur :/var/lock est renvoyé vers /run/lock par des liens symboliques sur Mageia 9
Pour ce qui est dans /var/lock, les droits sont identiques à Mageia 9 également, le lien symbolique est également présent dans Mageia 10. Dans le doute j'ai tout de même créé le répertoire sane, avec les droits 660 et le groupe scanner. Je suis aller aussi jusqu'à même lui donner les droits total.
Cela n'a rien changé.
Papoteur :Soit l'utilisateur n'a pas les droits d'écriture dans le répertoire, soit le verrou existe déjà.
nic80 :Je penche pour la première hypothèse.
J'y suis allé un peu à la barbare, mais en changeant le droit de /run/lock en root:scanner et 775 cela fonctionne.
Suite à ça je suis allé voir ce qu'il y avait dans le répertoire.
On retrouve ceci :
Code :
-rw-r--r-- 1 monuser monuser 17 mars 17 19:18 LCK..libusb:003:008
Et ce LCK semble rester
Sur Mageia 9 il n'y a pas cette création de LCK.
Mais je n'aime pas trop changer les droits de /run/lock, je vais donc restaurer les droits initiaux et chercher une autre solution.
Merci pour tous vos retours, cela permet de débloquer le scan sur ce poste si nécessaire !
Dès que j'aurai une autre solution je posterai ici.
Merci encore !
Édité par Rick399 Le 17/03/2026 à 20h53
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Les droits sur /var/lock (ou /run/lock) n' ont pas de bit particulier permttant n' importe quel user à écrire dedans mais où seul l'utilisateur qui l' a crée peut le supprimer ?
Si le fichier de verrouilage n' est pas crée sous Mageia 9, le comportement de Sane, libusb a changé entre les deux versions.
edit: de ce que comprends des fichiers spec de sane, une fichier /var/lib/lock/sane est crée avec un stickybit ( du coup le répertoire appartient à root, mais un fichier crée dedans ne peut être supprimé que par l' utilisateur qui l' a crée ou root)) par le paquet.
De ce que je comprends aussi, c' est que le répertoire de lock peut être défini lors de la compilation ( et donc si le chemin n' est pas bon, peut être que le répertoire de lock est /var/lock qui lui n' a pas de stickybit ce qui empêche la création du fichier ( mais je n' ai rien trouvé dans ce sens). Si on fait un strace sous Mageia 9, je suppose que c' est le /var/lib/lock/sane qui est utilisé.
Édité par nic80 Le 18/03/2026 à 00h02
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
Le chemin /var/lib/lock/sane était utilisé par le passé, mais ce n'est plus le cas depuis https://gitlab.com/sane-project/backends/-/commit/b0655dc03e67de902bf98850b4460b188503c186
Maintenant, c'est /var/lib/lock
De plus "Note: The Plustek backend is currently the only backend that makes
use of this feature."
Ça pourrait être désactivé à la compilation.
Un rapport intéressant : https://gitlab.com/sane-project/backends/-/work_items/363
Dans la définition du paquet, il y a la création d'un répertoire /var/lib/lock/sane à l'installation, mais ceci est erroné car ça renvoie à un répertoire temporaire qui disparaît à l'extinction de la machine.
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
nic80 :De ce que je comprends aussi, c' est que le répertoire de lock peut être défini lors de la compilation ( et donc si le chemin n' est pas bon, peut être que le répertoire de lock est /var/lock qui lui n' a pas de stickybit ce qui empêche la création du fichier ( mais je n' ai rien trouvé dans ce sens). Si on fait un strace sous Mageia 9, je suppose que c' est le /var/lib/lock/sane qui est utilisé.
Je n'ai pas vu de trace du sous-répertoire sane, il semble que ce soit une référence des rapports de bogues anciens. Sa suppression date de 2021.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie