Date: Fri, 22 Aug 2008 11:37:38 +0200 From: "Alexander Leidinger" <Alexander@Leidinger.net> To: "Kris Kennaway" <kris@FreeBSD.org> Cc: freebsd-usb@FreeBSD.org Subject: Re: usb4bsd patch review Message-ID: <20080822113738.75855zbz0hkckp8o@webmail.leidinger.net> In-Reply-To: <48AE7FFA.7070502@FreeBSD.org> References: <48AD9B9A.8070403@FreeBSD.org> <200808211856.47568.hselasky@c2i.net> <48ADA66A.3040906@FreeBSD.org> <20080821.115210.-524876976.imp@bsdimp.com> <20080822102925.12906gou50yqgpvw@webmail.leidinger.net> <48AE7FFA.7070502@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting "Kris Kennaway" <kris@FreeBSD.org> (from Fri, 22 Aug 2008 =20 10:59:38 +0200): > Alexander Leidinger wrote: >> Quoting "M. Warner Losh" <imp@bsdimp.com> (from Thu, 21 Aug 2008 =20 >> 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 =20 >>> is : > mostly to >>> : > view the currently attached USB devices, where the USB devices =20 >>> : > 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, =20 >>> which means you >>> : > must be either UID=3Droot or GID=3DOPERATOR to be able to use USB = =20 >>> : > 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 =20 >> rights (devfs.rules or manual chown/chmod by root) does not work =20 >> with the new usb stuff? If the answer is yes, I would see this as =20 >> some kind of nasty bug (I don't think this shall be a showstopper, =20 >> 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 =20 HPS is circumventing the normal devfs infrastructure and that this may =20 or may not be a problem and should be reviewed by someone with =20 knowledge about the devfs infrastructure? And as he mentioned that in the context of the userland utilities, it =20 may be interesting if this means if an USB specific userland utility =20 will be responsible to change the ownership and file access or not. If =20 yes, what are the consequences from a security point of view and what =20 about POLA (devfs.rules, chown/chmod)? I want to see this new USB subsystem, but if the answer to the above =20 paragraph is yes, then this would be a showstopper for me (IMO the =20 replacement should work in this regard as before, I don't say it can =20 not be changed after enough people agree that the replacement was =20 successful). Bye, Alexander. --=20 Such a fine first dream! But they laughed at me; they said I had made it up. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080822113738.75855zbz0hkckp8o>