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

[Sam Varshavchik]

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/001
[root@monster tmp]# getfacl /dev/bus/usb/006/001
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/006/001
# 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.

Where is this coming from? I don't use lirc any more, I did many years ago,  
so this must be the leftover from that era. I don't remember how I set it up  
back then.

Grepping through /etc for anything referencing the 'lirc' user, that might  
be specifying the ACLs for USB devices, doesn't find anything.

[Tony Nelson]

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/001
>  [root@monster tmp]# getfacl /dev/bus/usb/006/001
>  getfacl: Removing leading '/' from absolute path names
>  # file: dev/bus/usb/006/001
>  # 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`

-- 
____________________________________________________________________
TonyN.:'                       <mailto:[e-mail]>
       '                              <http://www.georgeanelson.com/>

[Sam Varshavchik]

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.

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.

[Todd Zullinger]

Sam Varshavchik wrote:
>  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. 
/etc is fine for local system config files and udev uses
them.  Rules files from packages are placed in /usr/lib.
Having default configuration outside of /etc is not
uncommon.  This is described in the second section of
udev(1):

   The udev rules are read from the files located in the
   system rules directory /usr/lib/udev/rules.d, the
   volatile runtime directory /run/udev/rules.d and the
   local administration directory /etc/udev/rules.d. All
   rules files are collectively sorted and processed in
   lexical order, regardless of the directories in which
   they live. However, files with identical filenames
   replace each other. Files in /etc have the highest
   priority, files in /run take precedence over files with
   the same name in /usr/lib. This can be used to override a
   system-supplied rules file with a local file if needed; a
   symlink in /etc with the same name as a rules file in
   /usr/lib, pointing to /dev/null, disables the rules file
   entirely. Rule files must have the extension .rules;
   other extensions are ignored.

-- 
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The secret to success is knowing who to blame for your failures.
    -- Demotivators (www.despair.com)

[Stephen Morris]

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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> 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/[e-mail]

[Sam Varshavchik]

Stephen Morris writes:

>  On 12/11/18 4:10 pm, Sam Varshavchik wrote:
> >
> >> 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. 
Nothing at boot time removes anything in the /dev directory, or the  
directory itself.

That's because, you'll be surprised to learn that the /dev directory does  
not exist in the first place. This is why I was specifically interested in  
figuring out where the ACLs get properly specified, and why manually setfacl- 
ing anything in /dev will never work.

You see, the /dev directory is a figment of your imagination.

If you poured over your root filesystem's raw disk blocks, looking for this  
mysterious /dev directory, you will never find it.

As such, it is logically impossible for anything to be automatically  
preserved across boots, since it never existed in the first place.

The last time an actual /dev directory existed, in its flesh and blood, on  
Linux, was decades ago. The /dev directory you see now is a virtual  
filesystem, that gets created from scratch on boot.

That's why trying to fix device permissions by chmod-ing or ACLing /dev  
entries is an exercise in futility. It will be gone at the next boot.  
Because it never actually really existed in the first place.

At least not until someone goes ahead and implements something that  
preserves existing /dev ownership and permission before shutting down, and  
restoring it at the next boot. That will never happen, of course, for the  
very precise reason of /dev being the way it is, and, more importantly, why.

[Tom Horsley]

On Mon, 12 Nov 2018 17:16:10 -0500
Sam Varshavchik wrote:

>  At least not until someone goes ahead and implements something that 
>
>  preserves existing /dev ownership and permission before shutting down, and  
>  restoring it at the next boot. That will never happen, of course, for the  
>  very precise reason of /dev being the way it is, and, more importantly, why. 
It's called running a script with a few second delay from rc.local :-).

I used to create a /dev/dvd link that way till I finally found
all the settings in user program that had "dev/dvd" stored
in them and changed them to /dev/sr0 :-).

Of course systemd has made it virtually impossible to
background anything in rc.local, my rc.local now looks like

#!/bin/sh
/usr/bin/at -M now <<'HERE' > /dev/null 2>&1
/etc/rc.d/the-real-rc.local
HERE

And everything I used to run in rc.local now gets run
from the-real-rc.local, untouched by systemd meddling
(resistance it futile, you will be assimilated).