[prev in list] [next in list] [prev in thread] [next in thread]
List: sun-managers
Subject: /etc/minor_perm apparently being ignored?
From: "James Noyes (SunManagers)" <jnoyes-sml () retrogeeks ! com>
Date: 2014-07-08 22:00:35
Message-ID: 20140708160035.Horde.V87y9TkthbXT02rI_dlRuQ2 () mail ! minihardware ! com
[Download RAW message or body]
Apologies for a ridiculously long post, I'm trying to be thorough on
covering what I've done so far and what's actually broken. I thought
I understood devices, driver binding, and node creation well enough,
but... apparently not.
So I'm trying to set up monitoring/operation of some APC UPS's via USB
under Solaris 10. I have everything in place physically and
software-wise, and it all DOES work, so I'm not trying to fix any
issue with the *functionality* of the solution as a whole. All I'm
trying to do is figure out why I'm forced to manually change the
permissions and ownership of the device nodes involved when I simply
*shouldn't have to*.
The driver that binds to the UPS's USB devices and the device nodes
that get created for them are by default "hid" class devices. This
seems to be a result of them being "class3" compatible, and the
corresponding entry in /etc/driver_aliases:
$ prtconf -v
<<<snip>>>
name='usb-product-name'
type=string items=1
value='Smart-UPS 1500
RM FW:617.3.D USB FW:1.5'
name='usb-vendor-name'
type=string items=1
value='American Power
Conversion'
<<<snip>>>
name='compatible'
type=string items=9
value='usb51d,2.6' +
'usb51d,2' + 'usbif51d,class3.0.0' + 'usbif51d,class3.0' +
'usbif51d,class3' + 'usbif,class3.0.0' + 'usbif,class3.0' +
'usbif,class3' + 'usb,device'
<<<snip>>>
$ grep hid /etc/driver_aliases
hid "usbif,class3"
But since the Solaris "hid" driver doesn't support anything but
keyboard and mouse, and because the monitoring software requires
libusb for accessing them, it becomes necessary to force the "ugen"
driver to bind to them instead. Also, since the monitoring software
runs unprivileged, I need to have the UPS devices accessible by
non-privileged users (this is where my whole problem pops up). I can
allegedly accomplish this whole setup with no problems using a simple
add_drv:
# add_drv -a -i '"usb51d,2"' -m '* 0666 root sys' ugen
After this, the updates to the device config files look good:
$ grep ugen /etc/driver_aliases
ugen "usb51d,2"
$ grep ugen /etc/minor_perm
ugen:* 0666 root sys
And the ugen driver binds happily to the devices, as shown by both
prtconf and /etc/path_to_inst:
$ grep ugen /etc/path_to_inst
"/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1" 0 "ugen"
"/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2" 1 "ugen"
$ prtconf -D | grep ugen
input, instance #0 (driver name: ugen)
input, instance #1 (driver name: ugen)
The dev and device nodes get created, and everything seems to look good:
$ find /dev/usb/51d.2
/dev/usb/51d.2
/dev/usb/51d.2/0
/dev/usb/51d.2/0/cntrl0stat
/dev/usb/51d.2/0/devstat
/dev/usb/51d.2/0/if0in1
/dev/usb/51d.2/0/cntrl0
/dev/usb/51d.2/0/if0in1stat
/dev/usb/51d.2/1
/dev/usb/51d.2/1/if0in1
/dev/usb/51d.2/1/cntrl0
/dev/usb/51d.2/1/if0in1stat
/dev/usb/51d.2/1/devstat
/dev/usb/51d.2/1/cntrl0stat
$ ls -la /dev/usb/51d.2/*/*
lrwxrwxrwx 1 root root 90 Jul 8 00:55
/dev/usb/51d.2/0/cntrl0 ->
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.cntrl0
lrwxrwxrwx 1 root root 94 Jul 8 00:55
/dev/usb/51d.2/0/cntrl0stat ->
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.cntrl0stat
lrwxrwxrwx 1 root root 91 Jul 8 00:55
/dev/usb/51d.2/0/devstat ->
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.devstat
lrwxrwxrwx 1 root root 90 Jul 8 00:55
/dev/usb/51d.2/0/if0in1 ->
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.if0in1
lrwxrwxrwx 1 root root 94 Jul 8 00:55
/dev/usb/51d.2/0/if0in1stat ->
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.if0in1stat
lrwxrwxrwx 1 root root 90 Jul 8 00:55
/dev/usb/51d.2/1/cntrl0 ->
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.cntrl0
lrwxrwxrwx 1 root root 94 Jul 8 00:55
/dev/usb/51d.2/1/cntrl0stat ->
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.cntrl0stat
lrwxrwxrwx 1 root root 91 Jul 8 00:55
/dev/usb/51d.2/1/devstat ->
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.devstat
lrwxrwxrwx 1 root root 90 Jul 8 00:55
/dev/usb/51d.2/1/if0in1 ->
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.if0in1
lrwxrwxrwx 1 root root 94 Jul 8 00:55
/dev/usb/51d.2/1/if0in1stat ->
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.if0in1stat
EXCEPT! The permissions on the device nodes are wrong!
$ ls -laL /dev/usb/51d.2/*/*
crw------- 1 root root 278, 2 Jul 8 14:30 /dev/usb/51d.2/0/cntrl0
crw------- 1 root root 278, 3 Jul 8 00:55
/dev/usb/51d.2/0/cntrl0stat
crw------- 1 root root 278, 1 Jul 8 00:55 /dev/usb/51d.2/0/devstat
crw------- 1 root root 278, 4 Jul 8 00:55 /dev/usb/51d.2/0/if0in1
crw------- 1 root root 278, 5 Jul 8 00:55
/dev/usb/51d.2/0/if0in1stat
crw------- 1 root root 278, 514 Jul 8 14:30 /dev/usb/51d.2/1/cntrl0
crw------- 1 root root 278, 515 Jul 8 00:55
/dev/usb/51d.2/1/cntrl0stat
crw------- 1 root root 278, 513 Jul 8 00:55
/dev/usb/51d.2/1/devstat
crw------- 1 root root 278, 516 Jul 8 00:55 /dev/usb/51d.2/1/if0in1
crw------- 1 root root 278, 517 Jul 8 00:55
/dev/usb/51d.2/1/if0in1stat
Huh? What did I do wrong? Everything I know (thought I knew?) about
the above procedure suggests that the devices should be permission 666
root:sys, not 600 root:root. What's even more annoying is that the
permissions aren't even what I would have expected if it was the "hid"
driver getting in the way, since the "hid" driver should create them
as 600 root:sys!
$ grep hid /etc/minor_perm
hid:* 0600 root sys
I'm also mystified as to where the "input@1" and "input@2" designators
in the /devices/... entries are coming from. There's no such thing as
an "input" driver, and there's no reference to "input" in either the
device config files or in the prtconf output, other than the device
nodes themselves! The word suggests it's maybe related to the "hid"
driver somehow, but I can't find the connection.
$ grep input /etc/driver_aliases /etc/driver_classes /etc/minor_perm
/etc/name_to_major /etc/name_to_sysnum
$
$ prtconf -D | grep input
input, instance #0 (driver name: ugen)
input, instance #1 (driver name: ugen)
$ prtconf -v | grep input
input, instance #0
dev_path=/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.devstat
dev_path=/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.cntrl0
dev_path=/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.cntrl0stat
dev_path=/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.if0in1
dev_path=/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.if0in1stat
input, instance #1
dev_path=/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.devstat
dev_path=/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.cntrl0
dev_path=/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.cntrl0stat
dev_path=/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.if0in1
dev_path=/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.if0in1stat
Mysteries aside, if I chown/chmod the device nodes, everything is
fine. All the software works. It can connect to the UPS's and
monitor/control them. So I have *functionality*, and I don't need to
worry about or fix that. But if the USB connections are
unplugged/replugged, or if I reconfigure boot, or even if I run
devfsadm, the permissions on the device nodes get reset back to 0600
root:root, and I'm left WITHOUT functionality until I manually
chown/chmod them again.
I've pondered this for a while, and I've come up empty. The
configuration I've done SHOULD work and set the permissions correctly.
I thought maybe the "hid" driver was interfering or causing
weirdness. I don't use any other "hid" devices on this system, so I
did a "rem_drv hid" but the problem still persists. I've unplugged
the devices, deleted the symlinks from /dev/usb and the device entries
from /etc/path_to_inst, done a reconfiguration boot, and when I plug
them back in, they STILL have the wrong permissions.
Have I overlooked something in configuring /etc/minor_perm? The other
entries in that file all seem to work perfectly (like /dev/cua/a being
600 uucp:uucp, for example).
Is there some sort of wrong information about these device nodes and
their permission being cached somewhere? The only remaining place
where it looks like there MIGHT be such a thing is in /dev/.devlink_db
(where I also see the "input"):
$ strings /dev/.devlink_db | grep 51d
51d.2.devstat
usb/51d.2/0/devstat
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.devstat
51d.2.cntrl0
usb/51d.2/0/cntrl0
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.cntrl0
51d.2.cntrl0stat
usb/51d.2/0/cntrl0stat
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.cntrl0stat
51d.2.if0in1
usb/51d.2/0/if0in1
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.if0in1
51d.2.if0in1stat
usb/51d.2/0/if0in1stat
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@1:51d.2.if0in1stat
51d.2.devstat
usb/51d.2/1/devstat
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.devstat
51d.2.cntrl0
usb/51d.2/1/cntrl0
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.cntrl0
51d.2.cntrl0stat
usb/51d.2/1/cntrl0stat
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.cntrl0stat
51d.2.if0in1
usb/51d.2/1/if0in1
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.if0in1
51d.2.if0in1stat
usb/51d.2/1/if0in1stat
../../../../devices/pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@3/input@2:51d.2.if0in1stat
But I'm VERY wary of doing anything to manipulate that file since
there's little to no documentation about it. I don't know if it's
something that the system will rebuild on its own, or if
damaging/deleting it will cause the system to melt down and need to be
rebuilt.
Any gurus out there with experience in tweaking drivers and device
node permissions have any suggestions? It seems silly to have
something so simple just not seem to work. The system SHOULD be
perfectly capable of having those devices come and go without me
having to go in and manipulate their ownership and permissions EVERY
SINGLE TIME.
If I can get it to work, I'll definitely summarize. Meanwhile, I'm
out of ideas.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic