From owner-freebsd-usb@FreeBSD.ORG Sat Aug 23 15:05:18 2008 Return-Path: Delivered-To: freebsd-usb@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A66C1106566C; Sat, 23 Aug 2008 15:05:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3218FC20; Sat, 23 Aug 2008 15:05:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7NF1WLW000640; Sat, 23 Aug 2008 09:01:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 23 Aug 2008 09:02:05 -0600 (MDT) Message-Id: <20080823.090205.-696512487.imp@bsdimp.com> To: hselasky@c2i.net From: "M. Warner Losh" In-Reply-To: <200808231034.54484.hselasky@c2i.net> References: <200808230804.03275.hselasky@c2i.net> <20080823093940.179e54ec@deskjail> <200808231034.54484.hselasky@c2i.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: phk@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb4bsd patch review X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 15:05:18 -0000 In message: <200808231034.54484.hselasky@c2i.net> Hans Petter Selasky 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 (Sat, 23 Aug 2008 08:03:55 : +0200): : > > On Friday 22 August 2008, Alexander Leidinger wrote: : > > > Quoting "Kris Kennaway" (from Fri, 22 Aug 2008 : > > > : > > > 10:59:38 +0200): : > > > > Alexander Leidinger wrote: : > > > >> Quoting "M. Warner Losh" (from Thu, 21 Aug 2008 : > > > >> : > > > >> 11:52:10 -0600 (MDT)): : > > > >>> In message: <48ADA66A.3040906@FreeBSD.org> : > > > >>> : > > > >>> Kris Kennaway 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" : :