[arch-general] nut UPS driver (upsdrvctl) fails to start for usbhid devices due to node perms - howto fix?

[David C. Rankin]

Guys,

  As a follow-on to the thread "package: network-ups-tools what happened to it?"
I have discussed the fail-to-start issue with the nut developers and the reason
why nut used to just "work" in the past for usb devices, but now no longer does
without additional configuration. This apparently has to do with hotplug/udev
permissions on newer Linux systems. I guess this went into Arch about 12-18
months ago, because that is when nut stopped working without further configuration.

  After working through errors starting the latest nut from git with systemd,
the problem was that /dev/bus/usb/004/002 is owned by root:root forcing
nut-driver.server to fail to start. Essentially upsdrvctl could not find/connect
with /dev/bus/usb/004/002 and could not find the ups usb connection. Modifying
the Execstart=/usr/bin/upsdrvctl start to:

/usr/bin/upsdrvctl -u root start <upsname>

allowed upsdrvctl to connect, but then created the state files in /var/state/ups
with root:root permission which in turn caused nut-server.service (upsd) to fail
on startup. upsd could not read the device files created in the state directory
and could not create the upsd.pid as it was running gid "nut".

  Changing gid ownership of /dev/bus/usb/004/002 to root:nut solves all problem
and allows upsdrvctl, upsd and upsmon to all start and connect fine. However,
there is no way for the packager to know what bus a device with install or or
whether it will be plugged back into the same port each time. I would like to
investigate how Arch could be changed/configured so that nut simply runs out of
the box as it used to before what ever changed changed. Is there a way the
packager can do this?

  There are articles about rolling custom udev files -- that essentially
accomplish linking the device to systemd and the ups name through /etc/ups/ups.conf:

http://www.kepstin.ca/blog/networkupstoolsnutandsystemd/

  That too is something impossible for the packager to take into account when
building the package.

  How do we package something like nut just works after it is installed like it
used to? Essentially, what is broken is nut's ability to probe and connect to
the ups device on startup due to the default device permissions.

  Did the usb devices used to have 0666 permissions in the past? That's the only
way I can see upsdrvctl being able to probe/connect to the device right out of
the box. What are the security consideration of having a usb device world
writable? Could we modify the default Arch udev setup to recognize UPS devices
and make these world writable by default?

  I don't know much about the new udev/usb logic, so I'm asking, what say the
experts?

-- 
David C. Rankin, J.D.,P.E.