Re: Where are the ACLs on /dev/usb devices specified?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/11/18 4:10 pm, Sam Varshavchik wrote:
Tony Nelson writes:

On 18-11-11 18:43:45, Sam Varshavchik wrote:
I'm trying to get NUT running. It fails to start because it setuids
itself to the nut user and then attempts to open the USB device node,
/dev/bus/usb/006/001

This fails with EACCESS because:

[root@monster tmp]# ls -al /dev/bus/usb/006/001
crw-rw-r--+ 1 root root 189, 640 Nov 11 13:49 /dev/bus/usb/006/002
[root@monster tmp]# getfacl /dev/bus/usb/006/002
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/006/002
# owner: root
# group: root
user::rw-
group::rw-
group:lirc:rw-
mask::rw-
other::r--

So the ACLs give access to USB devices to the 'lirc' user, and 'nut' can't open this.
 ...

I don't know about ACLs, but how about:

setfacl -m u:nut:rw /dev/bus/usb/006/001

from `man setfacl`

That'll work until the next reboot, when everything gets reset.

Just my two cents worth, from my usage of setfacl against directories I use it on, if the command setfacl -mR user:nut:rwx /dev/bus/usb/006/001 is issue it will remain across boots unless something at boot time is removing it.


regards,

Steve



Anyway, after poking around I found /usr/lib/udev/rules.d. nut installed a nice config file in there that enumerated all the USB vendor+product IDs and made the corresponding USB device nodes' permissions accessible to nut.

Unfortunately, the lirc-core package installed its own set of rules that overrode that, and, somewhat aggresively, claimed all usb devices for its own use, and reset their ACLs. This is a bug in the lirc-core package, and fully uninstalling lirc-core fixed this. Created bug 1648766 to document this.

P.S. This is really an awesome directory to dump configuration files into: /usr/lib/udev/rules.d. Apparently, /etc is not good enough, for udev.


_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux