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.
Rick399 Membre non connecté
-
- Voir le profil du membre Rick399
- Inscrit le : 13/03/2026
- Groupes :
nic80 :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 ?
Non, le bit était présent que dans /var/lib/lock/sane et uniquement sur Mageia 9.
Je trouve respectivement.
Pour /var :
Code :
lrwxrwxrwx 1 root root 11 févr. 15 18:48 lock -> ../run/lock/
Pour /run :
Code :
drwxr-xr-x 5 root root 160 mars 18 18:15 lock/
Identique sur les 2 versions de Mageia.
nic80 :Si le fichier de verrouilage n' est pas crée sous Mageia 9, le comportement de Sane, libusb a changé entre les deux versions.
Effectivement il n'y a pas de fichier de verrouillage du tout sour Mageia 9.
J'ai fais une strace et je ne vois pas de création de lock.
Pour le bloc "plustek" et alors que le scanner est bien détecté et opérationnel on obtient ceci :
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/002/001", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD, "/dev/bus/usb/001/005", O_RDWR|O_CLOEXEC) = 7
openat(AT_FDCWD, "/sys/bus/usb/devices/1-4/bConfigurationValue", O_RDONLY|O_CLOEXEC) = 8
read(8, "1\n", 19) = 2
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/003", 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/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 type)
openat(AT_FDCWD, "/etc/sane.d/plustek.conf", O_RDONLY) = 7
read(7, "# Plustek-SANE Backend configura"..., 4096) = 4096
read(7, "device, start with a new section"..., 4096) = 44
read(7, "", 4096) = 0
openat(AT_FDCWD, "/dev/bus/usb/001/005", O_RDWR|O_CLOEXEC) = 7
openat(AT_FDCWD, "/sys/bus/usb/devices/1-4/bConfigurationValue", O_RDONLY|O_CLOEXEC) = 8
read(8, "1\n", 19) = 2
read(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
Fichier complet : strace-scanimageL-openat-mga9.txt
Dans le doute j'ai cherché "/lock" et "LCK" cela n'apparait jamais dans le fichier.
Aux emplacements suivants il n'y a aucune création de lock :
- /var/lock (Et par extension /run/lock également)
- /var/lib/lock/sane
Papoteur :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.
C'est une piste très intéressante !
Surtout que dans le fichier configure du paquet sane-1.4.0-2.mga10.src.rpm on retrouve :
Code :
--enable-locking activate device locking (default=yes, but only used by some backends)
En creusant un peu plus j'ai comparé les .rpm de Mageia 9 et Mageia 10.
Il y a un contrôle supplémentaire dans le paquet de Mageia 9 qui n'est pas présent dans le 10 :
Code :
LOCKPATH_GROUP=uucp
[...]
# check if the group does exist
lasterror=""
touch sanetest.file
chgrp $LOCKPATH_GROUP sanetest.file 2>/dev/null || lasterror=$?
rm -f sanetest.file
if test ! -z "$lasterror"; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: Group $LOCKPATH_GROUP does not exist on this system." >&5
$as_echo "$as_me: WARNING: Group $LOCKPATH_GROUP does not exist on this system." >&2;}
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: Locking feature will be disabled." >&5
$as_echo "$as_me: WARNING: Locking feature will be disabled." >&2;}
use_locking=no
Je pense que ce block désactive le lock. Je l'ai repris dans Mageia 10 et cela me ferai passer dans la condition pour désactiver le lock, ce qui je pense s'est passé sur Mageia 9.
Pour tester jusqu'au bout, il me faudrait compiler sane-backends et essayant l'argument --disable-locking. Ou en ajoutant le petit bout de script du dessus.
Ce sera pour le weekend je pense.
Édité par Rick399 Le 18/03/2026 à 19h40
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
Rick399 :
Il y a un contrôle supplémentaire dans le paquet de Mageia 9 qui n'est pas présent dans le 10 :
Code :LOCKPATH_GROUP=uucp
[...]
# check if the group does exist
lasterror=""
touch sanetest.file
chgrp $LOCKPATH_GROUP sanetest.file 2>/dev/null || lasterror=$?
rm -f sanetest.file
if test ! -z "$lasterror"; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: Group $LOCKPATH_GROUP does not exist on this system." >&5
$as_echo "$as_me: WARNING: Group $LOCKPATH_GROUP does not exist on this system." >&2;}
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: Locking feature will be disabled." >&5
$as_echo "$as_me: WARNING: Locking feature will be disabled." >&2;}
use_locking=no
Je pense que ce block désactive le lock. Je l'ai repris dans Mageia 10 et cela me ferai passer dans la condition pour désactiver le lock, ce qui je pense s'est passé sur Mageia 9.
Tu trouves ça où ? Je ne le vois pas dans le fichier sane.spec
Rick399 Membre non connecté
-
- Voir le profil du membre Rick399
- Inscrit le : 13/03/2026
- Groupes :
Papoteur :Tu trouves ça où ? Je ne le vois pas dans le fichier sane.spec
Dans le fichier config présent dans le sane-backends-1.1.1.tar.gz
Mais je viens de réaliser que vue l'emplacement ce n'est pas lié à la distribution je pense
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie