Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 Aug 2008 09:39:40 +0200
From:      Alexander Leidinger <Alexander@Leidinger.net>
To:        Hans Petter Selasky <hselasky@c2i.net>
Cc:        freebsd-usb@freebsd.org
Subject:   Re: usb4bsd patch review
Message-ID:  <20080823093940.179e54ec@deskjail>
In-Reply-To: <200808230804.03275.hselasky@c2i.net>
References:  <48AD9B9A.8070403@FreeBSD.org> <48AE7FFA.7070502@FreeBSD.org> <20080822113738.75855zbz0hkckp8o@webmail.leidinger.net> <200808230804.03275.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Hans Petter Selasky <hselasky@c2i.net> (Sat, 23 Aug 2008 08:03:55 +0200):

> On Friday 22 August 2008, Alexander Leidinger wrote:
> > Quoting "Kris Kennaway" <kris@FreeBSD.org> (from Fri, 22 Aug 2008
> >
> > 10:59:38 +0200):
> > > Alexander Leidinger wrote:
> > >> Quoting "M. Warner Losh" <imp@bsdimp.com> (from Thu, 21 Aug 2008
> > >>
> > >> 11:52:10 -0600 (MDT)):
> > >>> In message: <48ADA66A.3040906@FreeBSD.org>
> > >>>
> > >>>            Kris Kennaway <kris@freebsd.org> writes:
> > >>> : Hans Petter Selasky wrote:
> > >>> : > The USB stack will work fine without "usbconfig". Its purpose
> > >>>
> > >>> is : > mostly to
> > >>>
> > >>> : > view the currently attached USB devices, where the USB devices
> > >>> : > are located
> > >>> : > and to select a non-default USB configuration. One thing which
> > >>> : > might be missed is to change owner and permission of a USB device,
> > >>>
> > >>> which means you
> > >>>
> > >>> : > must be either UID=root or GID=OPERATOR to be able to use USB
> > >>> : > devices that
> > >>> : > create devices under /dev/ .
> > >>> :
> > >>> : OK great, this isn't critical either.  I think all of the issues I
> > >>> : raised are agreed upon now!
> > >>
> > >> Wait a moment. Does this mean the devfs stuff to handle the access
> > >> rights (devfs.rules or manual chown/chmod by root) does not work
> > >> with the new usb stuff? If the answer is yes, I would see this as
> > >> some kind of nasty bug (I don't think this shall be a showstopper,
> > >> as long as this is fixed later).
> > >
> > > Yes, he said it will be fixed later.
> >
> > You are aware that I point out that this may or may not suggest that
> > HPS is circumventing the normal devfs infrastructure and that this may
> > or may not be a problem and should be reviewed by someone with
> > knowledge about the devfs infrastructure?
> >
> > And as he mentioned that in the context of the userland utilities, it
> > may be interesting if this means if an USB specific userland utility
> > will be responsible to change the ownership and file access or not. If
> > yes, what are the consequences from a security point of view and what
> > about POLA (devfs.rules, chown/chmod)?
> >
> > I want to see this new USB subsystem, but if the answer to the above
> > paragraph is yes, then this would be a showstopper for me (IMO the
> > replacement should work in this regard as before, I don't say it can
> > not be changed after enough people agree that the replacement was
> > successful).
> >
> > Bye,
> > Alexander.
> 
> Hi Alexander,
> 
> You have to ask Paul Henning Kamp about that. He does not like the idea 
> about /dev/ being the inventory list.

We already have a lot of cloning devices, so it's not about showing a
device node in /dev or not, I'm talking about chmod/chflags/devfs.rules.

> Besides, there are no more visible /dev/ devices. All devices are so-called 
> cloneable and invisible, so you need a separate utility. The good news is 

No, devfs.rules is handling this case already, no need for another
utility:
---snip---
NAME
     devfs.rules -- devfs configuration information

DESCRIPTION
     The devfs.rules file provides an easy way to create and apply devfs(8)
     rules, even for devices that are not available at boot.

     For devices available at boot, see devfs.conf(5).
---snip---

With your new utility you are changing the security policy, and this
without discussing this in public (who is able to change the
permissions, are changes permanent and survive a reboot, ...). With
devfs.rules we already have a tested and reviewed feature where root
can configure access.

> that you can set the permissions on a USB subtree (a HUB and all subdevices) 
> before devices are eventually plugged !

I don't know of a scenario where this is useful, but I'm not surprised
if someone has an use for this. And I think this feature can be
available while respecting the current semantics of devfs and
devfs.rules (e.g. if your feature is used, give priority to it, else
respect devfs.rules).

Bye,
Alexander.

-- 
Ferengi Rule of Acquisition #7:
	 Keep your ears open.
		-- ST:DS9, "In the Hands of the Prophets"
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080823093940.179e54ec>