Date: Sat, 23 Aug 2008 09:02:05 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: hselasky@c2i.net Cc: phk@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb4bsd patch review Message-ID: <20080823.090205.-696512487.imp@bsdimp.com> In-Reply-To: <200808231034.54484.hselasky@c2i.net> References: <200808230804.03275.hselasky@c2i.net> <20080823093940.179e54ec@deskjail> <200808231034.54484.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200808231034.54484.hselasky@c2i.net>
Hans Petter Selasky <hselasky@c2i.net> writes:
: I think the solution is that you use "devd.conf" instead of "devfs.conf" to do
: this in the future.
No, I think it should be devfs.conf to control permissions, etc.
: The problem about "devfs.rules" with regard to USB is that you don't know what
: you are giving permissions to. A rule that gives permission to "/dev/ulpt0"
: will give permissions to the first printer you plug into the USB system. That
: is not neccessarily what the user wants.
It is. Until we have better wiring of devices to drivers, it will
have to do. Better to solve that problem more generically..
Warner
: --HPS
:
: On Saturday 23 August 2008, Alexander Leidinger wrote:
: > 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).
: _______________________________________________
: freebsd-usb@freebsd.org mailing list
: http://lists.freebsd.org/mailman/listinfo/freebsd-usb
: To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org"
:
:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080823.090205.-696512487.imp>