Permissões incorretas no symlink para / dev / ttyACM0 criadas pela regra do udev

1

Estou tentando configurar nomes de dispositivos consistentes para alguns dispositivos USB em meu servidor de automação residencial em uma VM Ubuntu 17.04 em execução no ESXi 6. Até o momento, tenho as seguintes regras em /etc/udev/rules.d/ 99-usb-serial.rules:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idproduct}=="6001", ATTRS{serial}=="A19DVOA", SYMLINK+="USBrfxcom", MODE="0660", GROUP="dialout"
KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="USBzwave2", MODE="0660", GROUP="dialout"
KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="USBzwave5", MODE="0660", GROUP="dialout"
KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", SYMLINK+="USBcul",    MODE="0660", GROUP="dialout"

A primeira regra com o vendorid 0403 e productid 6001 não é tão importante no momento, pois é o único dispositivo que aparece no intervalo / dev / ttyUSB *, ou seja, é sempre / dev / ttyUSB0, embora isso possa mudar no futuro, quando eu adicionar mais dispositivos. As regras 2-4 são as problemáticas, todas são acionadas por três dispositivos que eu tenho no intervalo / dev / ttyACM *. Após a reinicialização, cada dispositivo USB pode aparecer como qualquer um dos / dev / ttyACM0 / dev / ttyACM1 ou / dev / ttyACM2, gostaria que eles aparecessem como / dev / USBzwave2, / dev / USBzwave5 e /dev/USBcul.

A saída de sudo udevadm test -a -p $ (udevadm info -q caminho -n / dev / ttyACM1) me dá:

Reading rules file: /etc/udev/rules.d/99-usb-serial.rules
Reading rules file: /lib/udev/rules.d/99-vmware-scsi-udev.rules
rules contain 49152 bytes tokens (4096 * 12 bytes), 14768 bytes strings
2093 strings (26721 bytes), 1358 de-duplicated (12689 bytes), 736 trie nodes used
value '[dmi/id]sys_vendor' is 'VMware, Inc.'
value '[dmi/id]sys_vendor' is 'VMware, Inc.'
IMPORT builtin 'hwdb' /lib/udev/rules.d/60-serial.rules:7
IMPORT builtin 'usb_id' /lib/udev/rules.d/60-serial.rules:8
/sys/devices/pci0000:00/0000:00:17.0/0000:13:00.0/usb1/1-3/1-3.2/1-3.2:1.0: if_class 2 protocol 0
IMPORT builtin 'hwdb' /lib/udev/rules.d/60-serial.rules:8
IMPORT builtin 'path_id' /lib/udev/rules.d/60-serial.rules:15
LINK 'serial/by-path/pci-0000:13:00.0-usb-0:3.2:1.0' /lib/udev/rules.d/60-serial.rules:16
IMPORT builtin skip 'usb_id' /lib/udev/rules.d/60-serial.rules:19
LINK 'serial/by-id/usb-busware.de_CUL868-if00' /lib/udev/rules.d/60-serial.rules:23
GROUP 20 /etc/udev/rules.d/99-usb-serial.rules:4
MODE 0660 /etc/udev/rules.d/99-usb-serial.rules:4
LINK 'USBcul' /etc/udev/rules.d/99-usb-serial.rules:4
handling device node '/dev/ttyACM1', devnum=c166:1, mode=0660, uid=0, gid=20
preserve permissions /dev/ttyACM1, 020660, uid=0, gid=20
preserve already existing symlink '/dev/char/166:1' to '../ttyACM1'
found 'c166:1' claiming '/run/udev/links/\x2fUSBcul'
creating link '/dev/USBcul' to '/dev/ttyACM1'
preserve already existing symlink '/dev/USBcul' to 'ttyACM1'
found 'c166:1' claiming '/run/udev/links/\x2fserial\x2fby-id\x2fusb-busware.de_CUL868-if00'
creating link '/dev/serial/by-id/usb-busware.de_CUL868-if00' to '/dev/ttyACM1'
preserve already existing symlink '/dev/serial/by-id/usb-busware.de_CUL868-if00' to '../../ttyACM1'
found 'c166:1' claiming '/run/udev/links/\x2fserial\x2fby-path\x2fpci-0000:13:00.0-usb-0:3.2:1.0'
creating link '/dev/serial/by-path/pci-0000:13:00.0-usb-0:3.2:1.0' to '/dev/ttyACM1'
preserve already existing symlink '/dev/serial/by-path/pci-0000:13:00.0-usb-0:3.2:1.0' to '../../ttyACM1'
created db file '/run/udev/data/c166:1' for '/devices/pci0000:00/0000:00:17.0/0000:13:00.0/usb1/1-3/1-3.2/1-3.2:1.0/tty/ttyACM1'
ACTION=-p
DEVLINKS=/dev/serial/by-id/usb-busware.de_CUL868-if00 /dev/USBcul /dev/serial/by-path/pci-0000:13:00.0-usb-0:3.2:1.0
DEVNAME=/dev/ttyACM1
DEVPATH=/devices/pci0000:00/0000:00:17.0/0000:13:00.0/usb1/1-3/1-3.2/1-3.2:1.0/tty/ttyACM1
ID_BUS=usb
ID_MODEL=CUL868
ID_MODEL_ENC=CUL868
ID_MODEL_FROM_DATABASE=LUFA USB to Serial Adapter Project
ID_MODEL_ID=204b
ID_PATH=pci-0000:13:00.0-usb-0:3.2:1.0
ID_PATH_TAG=pci-0000_13_00_0-usb-0_3_2_1_0
ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
ID_PCI_INTERFACE_FROM_DATABASE=XHCI
ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
ID_REVISION=0000
ID_SERIAL=busware.de_CUL868
ID_TYPE=generic
ID_USB_CLASS_FROM_DATABASE=Communications
ID_USB_DRIVER=cdc_acm
ID_USB_INTERFACES=:020201:0a0000:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=busware.de
ID_VENDOR_ENC=busware.de
ID_VENDOR_FROM_DATABASE=Atmel Corp.
ID_VENDOR_ID=03eb
MAJOR=166
MINOR=1
SUBSYSTEM=tty
TAGS=:systemd:
USEC_INITIALIZED=5912804
Unload module index
Unloaded link configuration context.

Isso parece 99% do caminho para uma solução, mas, se eu estou lendo a saída corretamente, as regras parecem estar criando dois symlinks:

creating link '/dev/USBcul' to '/dev/ttyACM1'
preserve already existing symlink '/dev/USBcul' to 'ttyACM1'

A primeira linha parece boa, a segunda linha parece errada.

ls -l / dev / USB * fornece:

lrwxrwxrwx 1 root root 7 Oct  1 14:46 /dev/USBcul -> ttyACM1

Acho que deveria ser:

lrwxrwxrwx 1 root root 7 Oct  1 14:46 /dev/USBcul -> /dev/ttyACM1

Além disso, o grupo especificado na regra parece estar sendo ignorado, deve ser definido como dialout em vez de root, também, as permissões estão erradas, elas são 777 não 660. Suponho que esses problemas de permissão sejam causados pelo problema. link simbólico incorreto.

Então, o que estou perdendo? Parece que está me encarando, mas eu simplesmente não consigo ver.

    
por higgers 01.10.2017 / 15:55

1 resposta

1

Os dois links simbólicos no seu exemplo apontam para a mesma coisa. O segundo ( /dev/USBcul -> ttyACM ) é um symlink relativo. Um link simbólico relativo aponta para um arquivo no mesmo diretório em que o link simbólico reside, neste caso /dev .

As permissões nos links simbólicos não são usadas: o acesso ao arquivo de destino é determinado pelas permissões e pela propriedade do arquivo de destino. Um link simbólico obtém sua propriedade de usuário e grupo do uid e gid do processo que criou o link. No seu exemplo, o link foi criado pelo root. Mais uma vez, a propriedade do link tem pouco significado: o acesso ao arquivo apontado é determinado pela propriedade do arquivo de destino. Uma situação em que a propriedade do link é importante é quando está contida em um diretório com o conjunto de bits fixos; então somente o dono do link pode removê-lo.

Qual foi o seu problema novamente?

    
por 02.10.2017 / 10:19

Tags