FBSD-6 usb/scanner-access-rights
Holger Kipp
hk at alogis.com
Sun Nov 20 16:37:40 GMT 2005
Dear Roland,
thank you very much for your answer.
On Sun, Nov 20, 2005 at 03:04:22PM +0100, Roland Smith wrote:
> On Sun, Nov 20, 2005 at 02:16:24PM +0100, Holger Kipp wrote:
> >
> > Is there an easy way to name the devices a user might
> > be allowed to access rw, without compromising the system?
> > I don't want to give operator group to these users,
> > and I don't want to blindly allow access to some
> > da- or pass-devices where I cannot determine the order
> > of numbering easily.
>
> One thing you could do is make the groups usb and cdrom and make them
> the groups owning the relevant devices, e.g. by putting the following in
> /etc/devfs.rules:
>
> add path 'da*s*' mode 0660 group usb
> add path 'uscanner*' mode 0660 group usb
ah, I had the entry
"add path 'uscanner*' mode 0660 group usb"
missing in the devfs.rules-file
but this still does not help...
uscanner0 is here:
uscanner0: EPSON EPSON Scanner, rev 1.10/1.00, addr 2
sane-find-scanner has the following to say:
found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0
only if I also issue
# chown root:usb /dev/usb0
# chown root:usb /dev/usb1
# chown root:usb /dev/usb2
it will return
found USB scanner (vendor=0x04b8, product=0x011d) at /dev/uscanner0
this is not good either, because attaching the scanner to a different
device means I have to change this for all /dev/usb*, effectively
allowing read/write to all usb devices.
I wonder why I have to allow access to all devices from 0 to 2.
Attaching to a different hub(*):
uscanner0: at uhub2 port 2 (addr 2) disconnected
uscanner0: detached
uscanner0: EPSON EPSON Scanner, rev 1.10/1.00, addr 2
-> I also have to chgrp usb /dev/usb3
so all /dev/usb<x> up to the corresponding /dev/usb<y> where the
scanner is attached are needed. Strange!
(*) detaching gives:
uscanner0: at uhub3 port 1 (addr 2) disconnected
uscanner0: detached
> The ownership for the CD-ROM devices should be set in /etc/devfs.conf:
>
> # Give members of group cdrom access to the CD/DVD-ROM and DVD+RW via the
> # SCSI interface
> own xpt0 root:cdrom
> perm xpt0 0660
>
> own cd0 root:cdrom
> perm cd0 0660
> link cd0 cdrom
> link cd0 dvd
>
> own pass0 root:cdrom
> perm pass0 0660
>
> own cd1 root:cdrom
> perm cd1 0660
>
> own pass1 root:cdrom
> perm pass1 0660
>
> The user that must be able to use the CD-ROMs and scanner must be a
> member of the appropriate group.
>
Yes, but there is a problem with numbering of pass-devices:
with card-reader attached during boot, I have:
<SMSC 223 U HS-CF 1.95> at scbus0 target 0 lun 0 (da0,pass0)
<SMSC 223 U HS-MS 1.95> at scbus0 target 0 lun 1 (da1,pass1)
<SMSC 223 U HS-SM 1.95> at scbus0 target 0 lun 2 (da2,pass2)
<SMSC 223 U HS-SD/MMC 1.95> at scbus0 target 0 lun 3 (da3,pass3)
<HL-DT-ST DVDRAM GSA-4163B A102> at scbus2 target 0 lun 0 (pass4,cd0)
<HL-DT-ST RW/DVD GCC-4120B 2.01> at scbus2 target 1 lun 0 (pass5,cd1)
attaching card-reader afterwards gives different numbering:
after boot:
katrin# camcontrol devlist
<HL-DT-ST DVDRAM GSA-4163B A102> at scbus1 target 0 lun 0 (cd1,pass1)
<HL-DT-ST RW/DVD GCC-4120B 2.01> at scbus1 target 1 lun 0 (cd0,pass0)
after attaching cardreader:
katrin# camcontrol devlist
<HL-DT-ST DVDRAM GSA-4163B A102> at scbus1 target 0 lun 0 (cd1,pass1)
<HL-DT-ST RW/DVD GCC-4120B 2.01> at scbus1 target 1 lun 0 (cd0,pass0)
<SMSC 223 U HS-CF 1.95> at scbus4 target 0 lun 0 (da0,pass2)
<SMSC 223 U HS-MS 1.95> at scbus4 target 0 lun 1 (da1,pass3)
<SMSC 223 U HS-SM 1.95> at scbus4 target 0 lun 2 (da2,pass4)
<SMSC 223 U HS-SD/MMC 1.95> at scbus4 target 0 lun 3 (da3,pass5)
so allowing access to cd0/cd1 and corresponding pass0 and pass1 will
break if computer is booted with usb-cardreader attached. not good.
And: allowing specific users access to xpt might also not be a very
good idea according to the man-page:
Since the xpt driver allows direct access to the CAM subsystem, system
administrators should exercise caution when granting access to this
driver. If used improperly, this driver can allow userland applications
to crash a machine or cause data loss.
> If that is not fine-grained enough, maybe ACLs might help. See setfacl(1).
so we currently have:
- rights needed not only for the device itself, but also for the bus
and or control devices (pass<x>, usb<x>, xpt0)
- dynamic numbering (pass<x>).
I agree that usb is a nightmare and should never have happened.
Regards,
Holger Kipp
More information about the freebsd-stable
mailing list