From owner-freebsd-usb@freebsd.org Wed Mar 30 07:09:38 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63ECCAE24FD for ; Wed, 30 Mar 2016 07:09:38 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F1D5125D for ; Wed, 30 Mar 2016 07:09:37 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 69C411FE023; Wed, 30 Mar 2016 09:09:32 +0200 (CEST) Subject: Re: libusb permission error (?) when attempting to detach device which is not attached To: Conor , freebsd-usb@freebsd.org References: From: Hans Petter Selasky Message-ID: <56FB7C64.5090801@selasky.org> Date: Wed, 30 Mar 2016 09:12:36 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 07:09:38 -0000 On 03/29/16 22:05, Conor wrote: > Greetings, > > I'm unsure if this is the correct place for this discussion; if it is more > suitably discussed elsewhere, please let me know. > > Currently, I'm looking into an issue with a port (devel/openocd), whereby > attempting to detach a USB device fails due to, from what I can tell, a > permissions error. First, some background; > > The port's pkg-message suggests adding the following lines to > /etc/devfs.rules: > > ===== > [localrules=10] > add path 'ugen*' mode 0660 group operator > add path 'usb/*' mode 0660 group operator > add path 'usb' mode 0770 group operator > ====== > > ...such that members of the operator group may access attached hardware. > I've done so, and my user is a member of the operator group. The device in > question is an Olimex JTAG debugger, and I'm running 10.2-RELEASE. > > When starting OpenOCD as my user, it bombs out stating that > libusb_detach_kernel_driver() has failed with LIBUSB_ERROR_OTHER. When > starting as root, there is no error, and I can socat/telnet to the OpenOCD > server and flash/debug a target. > > Initially, it seemed that it was, indeed, a permissions issue: > > 1) Some initial investigation of the FreeBSD libusb implementation, and > kernel source, pointed at the failure being in privilege checking in the > ioctl handler for USB_IFACE_DRIVER_DETACH whereby a check for PRIV_DRIVER > fails (sys/dev/usb/usb_generic.c:2210) when running as my user. Naturally, > the check for su returns success when running as root. > > 1a) Given the permissions alluded to in /etc/devfs.rules above, should this > privilege check fail, given that the device node is one of ugenX.Y? Hi, Currently only root/superuser can alter the enumeration state of USB, like attaching/detaching kernel drivers. That's why there is a PRIV_DRIVER check in the IOCTL of USB_IFACE_DRIVER_DETACH. > > 2) I've patched the OpenOCD source to first check for an active driver with > libusb_kernel_driver_active(), and only on success, attempting to detach > the device. Whilst this rectifies the issue -- there is no active driver, > ergo, no detach attempt is made and I can use the server as described with > su, above -- is it reasonable/necessary to do this? Unlike Linux, interface drivers can co-exist in userspace and the kernel for the same USB device, given they are not in use at the same time. Currently this and other user-space drivers should call libusb_kernel_driver_active(), but don't bail out if libusb_kernel_driver_active() does not succeed. --HPS