4 votes

UlfR avatar

Comment les ACL sont-elles définies sur les périphériques USB ?

Demandé el 21 de Octobre, 2015
Quand la question a-t-elle été
2749 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Je suis novice en matière d'acl donc c'est du Blackmagic pour moi. Mais ce que j'ai, c'est une caméra à laquelle je veux parler.

J'ai donc obtenu une machine debian à démarrage par le réseau :

ulf@term13:~(0)$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 6.0.10 (squeeze)
Release:    6.0.10
Codename:   squeeze

Une caméra est attachée à cette machine :

ulf@term13:~(0)$ lsusb | grep Nikon
Bus 001 Device 092: ID 04b0:0428 Nikon Corp. 
ulf@term13:~(0)$ ls -alF /dev/bus/usb/001/092 
crw-rw-r--+ 1 root root 189, 91 25 sep 10.05 /dev/bus/usb/001/092

Notez le + à la fin de la chaîne de permissions crw-rw-r--+ . Cela indique qu'il y a un ACL au travail ici :

ulf@term13:~(1)$ getfacl /dev/bus/usb/001/092 
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/001/092
# owner: root
# group: root
user::rw-
user:knut:rw-
group::rw-
mask::rw-
other::r--

Apparemment, l'utilisateur knut a d'autres rw permissions ici. Mais comment les a-t-il eues ?

Je peux définir les mêmes permissions à mon utilisateur avec setfacl . Mais ce qui a été réglé ainsi ne sera plus présent après que la caméra ait été reconnectée. Après avoir allumé et éteint l'appareil photo, on obtient en fait monté sur un autre appareil :

ulf@term13:~(0)$ lsusb | grep Nikon
Bus 001 Device 093: ID 04b0:0428 Nikon Corp.

Mais les autorisations pour le nouveau périphérique 093 sont les mêmes que celles de l'ancien 092 (sans les autorisations supplémentaires que j'ai ajoutées au 092).

Il existe un udev -Ce fichier devrait être celui qui est en charge je pense, mais il est vide ? ??

ulf@term13:~(0)$ ls -alF /etc/udev/rules.d/90-libgphoto2.rules 
-rw-r--r-- 1 root root 0 26 aug  2014 /etc/udev/rules.d/90-libgphoto2.rules

Et aucun des autres fichiers udev ne contient d'éléments liés à cela.

Existe-t-il un fichier où cela est configuré ? Ceci est configuré par un administrateur système qui n'est plus présent ici, je dois donc le réparer moi-même.

Demandé el 21 de Octobre, 2015 par UlfR

Réponses

Trop de publicités?

5voto

James Mertz avatar
James Mertz Points 390

Apparemment, l'utilisateur knut a des permissions rw supplémentaires ici. Mais comment les a-t-il obtenus ?

L'utilisateur "knut" est-il connecté à la console ? Sur de nombreux systèmes Linux récents, udev accorde l'accès au périphérique en fonction de la personne qui est actuellement connectée.

(Ici, "console" signifie l'écran principal + le clavier). relié directement à l'ordinateur - que ce soit en mode texte ou graphique n'a aucune importance).

Les versions plus anciennes (y compris Debian 6) ont des règles avec TAGS+="udev-acl" et obtenir l'état de la session à partir de ConsoleKit s'il est présent, pam_console sinon. Vérifier who le contenu de /var/run/console et peut-être ck-list-sessions . Ces mécanismes sont relativement simples - si l'utilisateur est connecté à la "console", il y a accès, sinon non.

Les distributions utilisant systemd prennent les mêmes informations à partir de systemd-logind et utiliser le "uaccess" à la place. En plus de la console, logind prend également en charge les systèmes "multi-sièges", où plusieurs utilisateurs peuvent travailler sur plusieurs écrans en même temps, chacun ayant un port USB assigné.

Si vous voulez contourner cela et accorder l'accès à d'autres utilisateurs, vous pouvez utiliser les permissions traditionnelles de "groupe" pour cela - écrivez une règle udev assignant votre dispositif à GROUP="camera-users" et ajouter des personnes à ce groupe.

Après avoir allumé et éteint les caméras, elles sont montées sur un autre appareil :

ulf@term13:~(0)$ lsusb | grep Nikon
Bus 001 Device 093: ID 04b0:0428 Nikon Corp.

Sous Linux (et généralement sous les Unix), "mount" fait référence à l'attachement d'un système de fichiers à un répertoire ("/dev/sda2 is mounted on /boot" - le système de fichiers que /dev/sda2 contient a été rendu accessible à /boot). En revanche, les numéros de périphériques USB ne sont que des numéros, attribués de manière séquentielle ; cela ne constitue pas un "montage" du périphérique.

Répondu el 21 de Octobre, 2015 par James Mertz (390 Points )

0voto

graeme vetterlein avatar
graeme vetterlein Points 1

OK, je vois un comportement similaire. Il y a une règle udev :

$ cat /etc/udev/rules.d/50-blinkstick.rules 
# This file is installed by libbs to enable write access to BlinkStick devices
# to any seated user

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="20a0", ATTRS{idProduct}=="41e5", TAG+="uaccess", TAG+="udev-acl"

# vim: ft=udevrules

Et en effet, il utilise uaccess. Mais si je regarde le fichier (/dev/bus/usb/001/003), je vois des perms normaux et une ACL m'accordant l'accès. Si je me connecte via une autre pseudo console (ctrl-alt-Fn) et un autre utilisateur, je vois une entrée ACL donnant accès à "moi" (uid différent).

donc getfacl pour différents utilisateurs sur le même fichier retourne des ACL différentes :

1 : Ce comportement semble très incorrect

2 : Je ne vois pas où il est documenté "donner à RW l'accès au siège0" ? Seulement les utilisateurs et les groupes (comme toujours)

AFYI : Le fichier /run/systemd/seats/seat0 comporte des fonctionnalités dans cette

Répondu el 14 de Août, 2019 par graeme vetterlein (1 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X