Re: [avr-chat] Avrdude Permissions On Linux

[Xiaofan Chen]

On 5/29/06, Chris Spencer <address@hidden> wrote:
> I have an AVR ISP mkII  programmer, and I can only access it with
> Avrdude when I'm root. As a normal user I get the error 'avrdude:
> usb_open(): cannot read serial number "error sending control message:
> Operation not permitted"'
> What permissions do you have to change to access the programmer as a
> normal user?


I am not an AVR user actually but you may want to refer to the
following post to the Linux libusb mailing list.

You will either need udev rules or hotplug scripts. I am using
Ubuntu and I have got PICkit 2 (a PIC programmer from Microchip)
working with hotplug scripts
(http://piklab.sourceforge.net/support.php).

If you are using FC5, maybe you have to use udev rules.

Regards,
Xiaofan

****************************************************
* From Linux libusb mailing list                   *
****************************************************

Linux specific installation information
=======================================

Since libusb is accessing the raw device nodes exported by the kernel
in order to identify connected USB busses, functions and such, it
needs to find these nodes. During the history of the Linux kernel,
the placement and the way of accessing these nodes have changed.

This placement is closely related to hotplugging: i.e. addition and
removal of USB functions at runtime.


Most current solution: use udev
===============================

The latest and greatest way of managing hotplugged (and cold-plugged)
devices under Linux is called "udev". This is a development of the
older "hotplug" system (see below).

When a device is connected, the kernel will call the program
/sbin/udev in order to create a device node in the /dev/ file
hirerarchy. It will also remove devices from this hierarchy when
they are unplugged.

Traditionally, all devices plugged into a Linux system are expected
to have a kernel device driver, or to load one on-the-fly when a
new device is connected. Libusb cannot use these device drivers,
instead it attempts to access the raw device nodes from user mode,
not as a kernel module.

In order for libusb to find the device node, it needs to locate it
in the /dev filesystem. The recommended way to let udev create nodes
in the /dev filesystem is to add a udev rule like the following into
some foo.rules file inside the /etc/udev/rules.d/ directory:

# usbfs-like devices
SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; \
printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", \
NAME="%c"

This layout is used by for example the Debian distribution. This
rule creates a device tree identical to the earlier /proc/bus/usb/
tree, but under /dev/bus/usb/ instead. If this device tree exists,
libusb will default to use it. It will look like this:

/dev
/bus
 /usb
   /001
     /001
     /002
     /003
  /002
     /001
     /002
     ...

However notice that the permissions on the nodes will be default
permissions: often this means they are only accessible for writing
by the root user, whereas non-root users often can access it
read-only.

The way of controlling access to a device node differs between
systems, but a typical way of complementing udev rules with
apropriate permissions is to use PAM (pluggable Authentication
Modules), with some sort of configuration under /etc/security/.
The use of /dev nodes is also different from the old usbfs
solution in that it enables the use of ACL:s (Access Control
Lists) to control acces for the USB device nodes.

A less good alternative that may however be useful for debugging
would be to supply the argument MODE="666" to the above udev
rule, or, slightly better, to tag on:

MODE="660", GROUP="foo"

where "foo" is a group of users (e.g. desktop users) that need
to access the device in read/write mode.

If libusb cannot find a device hierarchy below /dev/bus/usb/
(as is the case if you are not using udev, or not using it with
the above rule), it will fall back on using /proc/bus/usb/
instead.

Additionally, you may want to trigger unique actions for your
device at the same time. To do this, create a rules file
/etc/udev/rules.d/bar.rules with these lines:

SUBSYSTEM=="usb_device", ACTION=="add", SYSFS{idVendor}=="1234", \
SYSFS{idProduct}=="4321"

At the end of this line you can then tag on any device-specific
actions for device 1234/4321, for example:

MODE="660", GROUP="baz"   to set mode and group
RUN="/usr/local/bin/baz"  to run a script on plug-in
SYMLINK+="foo"            to create a symlink device node with
                       this name in /dev

You can read more about udev in its own documentation.


Previous solution: use hotplug
==============================

Before udev another system, generally considered less elegant,
known simply as "hotplug" was used. In this case the program
/sbin/hotplug would be called whenever devices were connected
or removed from the system, and the corresponding configuration
lives in /etc/hotplug/.

With hotplug not using udev at the same time, all devices are
accessed using the usbfs hierarchy below /proc/bus/usb/. Again,
this will be used by libusb, since libusb does not use any device
drivers. The hierarchy will look like this:

/proc
/bus
 /usb
   /001
     /001
     /002
     /003
  /002
     /001
     /002
     ...

When USB devices are plugged in, their corresponding device
node is created in /proc/bus/usb/ by the kernel, without any
external program intervention (as is the case with udev).

However, to correct the permissions on these device nodes, if
your device requires anything else than read access, you need
to supply a script in /etc/hotplug/usb/ that detects your
device and change its permissions, for example this
/etc/hotplug/usb/foo.usermap

# Foo device with VID=1234 and PID=4321
bar 0x0003 0x1234 0x4321 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000

(All this need to be in one line.)

The first string "bar" points out the name of a script placed
in /etc/hotplug/usb/bar, with for example the following contents:


#!/bin/bash
if [ "${ACTION}" = "add" ] && [ -f "${DEVICE}" ]
then

chgrp baz "${DEVICE}"
chmod 660 "${DEVICE}"
fi

to let users in the group "baz" access the device for reading
and writing.

You can read more about hotplug and its usermaps in the
hotplug documentation.

****************************************************
* End of the email from Linux libusb mailing list
****************************************************