Quand je branche mon appareil photo sur mon PC, je dois soit utiliser
gphoto2 en tant que root, soit faire un chmod a+w sur
/proc/bus/usb/001/<le numéro du device>
Comme le numéro du device change à chaque reconnexion de l'appareil, ça
n'est pas très pratique... Quoi configurer et comment pour changer les
droits par défaut?
--
Dix grammes d'abstraction valent des tonnes de bricolage.
Loi de Booker.
Donc les options sont prises en compte mais n'ont aucun effet.
J'ai creusé un peu, et dans /etc/hostplug, il y a un script usb.agent qui apparemment lance d'autres scripts et petmettrait en bidouillant de changer les uid/gid dynamiquement :
# # used to run config scripts for user mode drivers (jPhoto, gPhoto2, # rio500 tools, etc) ... instead of naming kernel modules, it names # config scripts. those could change $DEVICE permissions, etc. # # for purely user mode drivers, scripts $HOTPLUG_DIR/usb/NAME should be # installed with usermap files in $HOTPLUG_DIR/usb/NAME.usermap instead # of continuing to use/modify $MAP_USERMAP # MAP_USERMAP=$HOTPLUG_DIR/usb.usermap
Bon, je vais essayer de bricoler ce fichier usb.usermap.
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Mon, 14 Jun 2004 23:01:26 +0200, TiChou a écrit :
Est-ce que la commande suivante fait bien effet :
mount -o remount,devmode64,devgid /proc/bus/usb
Non, aucun. J'ai créé un groupe usb (103 chez moi) et modifié mon fstab
comme ceci :
Donc les options sont prises en compte mais n'ont aucun effet.
J'ai creusé un peu, et dans /etc/hostplug, il y a un script usb.agent qui
apparemment lance d'autres scripts et petmettrait en bidouillant de
changer les uid/gid dynamiquement :
#
# used to run config scripts for user mode drivers (jPhoto, gPhoto2,
# rio500 tools, etc) ... instead of naming kernel modules, it names
# config scripts. those could change $DEVICE permissions, etc.
#
# for purely user mode drivers, scripts $HOTPLUG_DIR/usb/NAME should be
# installed with usermap files in $HOTPLUG_DIR/usb/NAME.usermap instead
# of continuing to use/modify $MAP_USERMAP
#
MAP_USERMAP=$HOTPLUG_DIR/usb.usermap
Bon, je vais essayer de bricoler ce fichier usb.usermap.
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray
Donc les options sont prises en compte mais n'ont aucun effet.
J'ai creusé un peu, et dans /etc/hostplug, il y a un script usb.agent qui apparemment lance d'autres scripts et petmettrait en bidouillant de changer les uid/gid dynamiquement :
# # used to run config scripts for user mode drivers (jPhoto, gPhoto2, # rio500 tools, etc) ... instead of naming kernel modules, it names # config scripts. those could change $DEVICE permissions, etc. # # for purely user mode drivers, scripts $HOTPLUG_DIR/usb/NAME should be # installed with usermap files in $HOTPLUG_DIR/usb/NAME.usermap instead # of continuing to use/modify $MAP_USERMAP # MAP_USERMAP=$HOTPLUG_DIR/usb.usermap
Bon, je vais essayer de bricoler ce fichier usb.usermap.
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Emmanuel Florac
Le Tue, 15 Jun 2004 10:10:09 +0200, Emmanuel Florac a écrit :
Bon, je vais essayer de bricoler ce fichier usb.usermap.
Je ne comprends pas ce qu'on est supposé y mettre :/
Voilà le contenu du fichier (une seule ligne commentée):
-- Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est carrément impossible. Si ça a l'air impossible, c'est un compilateur Ada. Théorème de Stockmayer.
Le Tue, 15 Jun 2004 10:10:09 +0200, Emmanuel Florac a écrit :
Bon, je vais essayer de bricoler ce fichier usb.usermap.
Je ne comprends pas ce qu'on est supposé y mettre :/
Voilà le contenu du fichier (une seule ligne commentée):
--
Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est
carrément impossible. Si ça a l'air impossible, c'est un compilateur
Ada.
Théorème de Stockmayer.
-- Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est carrément impossible. Si ça a l'air impossible, c'est un compilateur Ada. Théorème de Stockmayer.
Nicolas George
Emmanuel Florac wrote in message :
Ah d'accord. Quoi qu'il en soit j'ai changé les options dans fstab, j'ai essayé de démonter, remoonter etc, rien n'y fait : toujours root.root/644, grrrrr.
J'ai le même problème, et après un examen plus détaillé, j'ai trouvé ceci : l'option devmode (et probablement les autres) n'est prise en compte que si usbdevfs est monté avant que le driver du contrôleur USB ne soit chargé. Je n'ai aucune idée de comment combiner ça avec une procédure de boot habituelle, j'ai bien peur qu'il faille faire un script ad-hoc.
Emmanuel Florac wrote in message
<pan.2004.06.15.08.04.53.133806@imaginet.fr>:
Ah d'accord. Quoi qu'il en soit j'ai changé les options dans fstab, j'ai
essayé de démonter, remoonter etc, rien n'y fait : toujours
root.root/644, grrrrr.
J'ai le même problème, et après un examen plus détaillé, j'ai trouvé
ceci : l'option devmode (et probablement les autres) n'est prise en
compte que si usbdevfs est monté avant que le driver du contrôleur USB
ne soit chargé. Je n'ai aucune idée de comment combiner ça avec une
procédure de boot habituelle, j'ai bien peur qu'il faille faire un
script ad-hoc.
Ah d'accord. Quoi qu'il en soit j'ai changé les options dans fstab, j'ai essayé de démonter, remoonter etc, rien n'y fait : toujours root.root/644, grrrrr.
J'ai le même problème, et après un examen plus détaillé, j'ai trouvé ceci : l'option devmode (et probablement les autres) n'est prise en compte que si usbdevfs est monté avant que le driver du contrôleur USB ne soit chargé. Je n'ai aucune idée de comment combiner ça avec une procédure de boot habituelle, j'ai bien peur qu'il faille faire un script ad-hoc.
TiChou
Dans le message <news:, *Emmanuel Florac* tapota sur f.c.o.l.configuration :
Est-ce que la commande suivante fait bien effet :
mount -o remount,devmode64,devgid /proc/bus/usb
Non, aucun. J'ai créé un groupe usb (103 chez moi) et modifié mon fstab comme ceci :
Normal. Si tu regardes bien mon premier post, le répertoire /proc/bus/usb n'est pas affecté avec les options devmode et devgig mais avec busmode, busuid et busgid.
Normal. Si tu regardes bien mon premier post, le répertoire /proc/bus/usb
n'est pas affecté avec les options devmode et devgig mais avec busmode,
busuid et busgid.
Normal. Si tu regardes bien mon premier post, le répertoire /proc/bus/usb n'est pas affecté avec les options devmode et devgig mais avec busmode, busuid et busgid.
Normal. C'est les options listmode, listuid et listgid qui modifient les permissions sur les fichiers /proc/bus/usb/{devices,drivers}.
Donc les options sont prises en compte mais n'ont aucun effet.
Mais tu ne regardes pas là où il faut. :)
$ ls -l /proc/bus/usb/*/*
-- TiChou
TiChou
Dans le message <news:caml04$1blo$, *Nicolas George* tapota sur f.c.o.l.configuration :
Emmanuel Florac wrote:
Ah d'accord. Quoi qu'il en soit j'ai changé les options dans fstab, j'ai essayé de démonter, remoonter etc, rien n'y fait : toujours root.root/644, grrrrr.
J'ai le même problème, et après un examen plus détaillé, j'ai trouvé ceci : l'option devmode (et probablement les autres) n'est prise en compte que si usbdevfs est monté avant que le driver du contrôleur USB ne soit chargé.
Où avez vous trouvé cette information ? Les tests que j'ai effectué sur un noyau 2.4.20 et un noyau 2.4.26, montrent que l'on peut modifier à chaud les permissions avec les options devmode et devgid et que les permissions sont effectives immédiatement mêmes sur les périphériques déjà branchés et gérés.
-- TiChou
Dans le message <news:caml04$1blo$1@biggoron.nerim.net>,
*Nicolas George* tapota sur f.c.o.l.configuration :
Emmanuel Florac wrote:
Ah d'accord. Quoi qu'il en soit j'ai changé les options dans fstab, j'ai
essayé de démonter, remoonter etc, rien n'y fait : toujours
root.root/644, grrrrr.
J'ai le même problème, et après un examen plus détaillé, j'ai trouvé
ceci : l'option devmode (et probablement les autres) n'est prise en
compte que si usbdevfs est monté avant que le driver du contrôleur USB
ne soit chargé.
Où avez vous trouvé cette information ?
Les tests que j'ai effectué sur un noyau 2.4.20 et un noyau 2.4.26, montrent
que l'on peut modifier à chaud les permissions avec les options devmode et
devgid et que les permissions sont effectives immédiatement mêmes sur les
périphériques déjà branchés et gérés.
Dans le message <news:caml04$1blo$, *Nicolas George* tapota sur f.c.o.l.configuration :
Emmanuel Florac wrote:
Ah d'accord. Quoi qu'il en soit j'ai changé les options dans fstab, j'ai essayé de démonter, remoonter etc, rien n'y fait : toujours root.root/644, grrrrr.
J'ai le même problème, et après un examen plus détaillé, j'ai trouvé ceci : l'option devmode (et probablement les autres) n'est prise en compte que si usbdevfs est monté avant que le driver du contrôleur USB ne soit chargé.
Où avez vous trouvé cette information ? Les tests que j'ai effectué sur un noyau 2.4.20 et un noyau 2.4.26, montrent que l'on peut modifier à chaud les permissions avec les options devmode et devgid et que les permissions sont effectives immédiatement mêmes sur les périphériques déjà branchés et gérés.
-- TiChou
TiChou
Dans le message <news:, *Emmanuel Florac* tapota sur f.c.o.l.configuration :
Bon, je vais essayer de bricoler ce fichier usb.usermap.
Je ne comprends pas ce qu'on est supposé y mettre :/
Voilà le contenu du fichier (une seule ligne commentée):
C'est les champs idVendor et idProduct qui sont importants et tu peux les récupérer dans les logs du noyau ou dans le fichier /proc/bus/usb/devices. Les autres champs sont généralement à 0. Tu peux aussi regarder les fichiers /lib/modules/`uname -r`/modules.usbmap ou /etc/hotplug/usb.*map.
-- TiChou
Dans le message <news:pan.2004.06.15.08.14.00.665236@imaginet.fr>,
*Emmanuel Florac* tapota sur f.c.o.l.configuration :
Bon, je vais essayer de bricoler ce fichier usb.usermap.
Je ne comprends pas ce qu'on est supposé y mettre :/
Voilà le contenu du fichier (une seule ligne commentée):
C'est les champs idVendor et idProduct qui sont importants et tu peux les
récupérer dans les logs du noyau ou dans le fichier /proc/bus/usb/devices.
Les autres champs sont généralement à 0.
Tu peux aussi regarder les fichiers /lib/modules/`uname -r`/modules.usbmap
ou /etc/hotplug/usb.*map.
C'est les champs idVendor et idProduct qui sont importants et tu peux les récupérer dans les logs du noyau ou dans le fichier /proc/bus/usb/devices. Les autres champs sont généralement à 0. Tu peux aussi regarder les fichiers /lib/modules/`uname -r`/modules.usbmap ou /etc/hotplug/usb.*map.
Les tests que j'ai effectué sur un noyau 2.4.20 et un noyau 2.4.26, montrent que l'on peut modifier à chaud les permissions avec les options devmode et devgid et que les permissions sont effectives immédiatement mêmes sur les périphériques déjà branchés et gérés.
J'essaie avec un 2.6, c'est probablement de là que viens la différence. Effectivement, quand j'étais en 2.4, devmode fonctionnait bien comme tu le décris.
"TiChou" wrote in message <gniii.20040615150518@florizarre.tichou.org>:
Les tests que j'ai effectué sur un noyau 2.4.20 et un noyau 2.4.26, montrent
que l'on peut modifier à chaud les permissions avec les options devmode et
devgid et que les permissions sont effectives immédiatement mêmes sur les
périphériques déjà branchés et gérés.
J'essaie avec un 2.6, c'est probablement de là que viens la différence.
Effectivement, quand j'étais en 2.4, devmode fonctionnait bien comme tu
le décris.
Les tests que j'ai effectué sur un noyau 2.4.20 et un noyau 2.4.26, montrent que l'on peut modifier à chaud les permissions avec les options devmode et devgid et que les permissions sont effectives immédiatement mêmes sur les périphériques déjà branchés et gérés.
J'essaie avec un 2.6, c'est probablement de là que viens la différence. Effectivement, quand j'étais en 2.4, devmode fonctionnait bien comme tu le décris.
