/dev/hidraw: read permissions

devicesudev

What do I need to do to have read permissions on /dev/hidraw*?

I'm seeing stuff about udev rules and saw this on the net, but the world of udev is like a foreign land to me, and if there's some sort of a simpler solution where I just add myself to a group that'd be dandy…

(Ubuntu 13.10 Preview)

Feel free to retag the question – I'm not too keen on what 'hidraw' exactly goes under.

EDIT:

H'okay, so, just some more information to clarify the issue:
I literally stepped through code that called the POSIX open() method, and got the errno for insufficient permissions. Running cat on the file as a normal user results in an insufficient permissions error, while running under su results in a successful (albeit meaningless) cat operation.

EDIT EDIT:

At request, I'm providing the relevant code with POSIX call. It's from the HIDAPI library by Signal11 (function hid_open_path). I trust that this code is correct, as it has apparently been in use for quite some time now. I've added a comment located where the relevant errno reading took place in GDB.

hid_device *dev = NULL;

hid_init();

dev = new_hid_device();

if (kernel_version == 0) {
    struct utsname name;
    int major, minor, release;
    int ret;
    uname(&name);
    ret = sscanf(name.release, "%d.%d.%d", &major, &minor, &release);
    if (ret == 3) {
        kernel_version = major << 16 | minor << 8 | release;
        //printf("Kernel Version: %d\n", kernel_version);
    }
    else {
        printf("Couldn't sscanf() version string %s\n", name.release);
    }
}

/* OPEN HERE */
dev->device_handle = open(path, O_RDWR);

// errno at this location is 13: insufficient permissions

/* If we have a good handle, return it. */
if (dev->device_handle > 0) {

    /* Get the report descriptor */
    int res, desc_size = 0;
    struct hidraw_report_descriptor rpt_desc;

    memset(&rpt_desc, 0x0, sizeof(rpt_desc));

    /* Get Report Descriptor Size */
    res = ioctl(dev->device_handle, HIDIOCGRDESCSIZE, &desc_size);
    if (res < 0)
        perror("HIDIOCGRDESCSIZE");


    /* Get Report Descriptor */
    rpt_desc.size = desc_size;
    res = ioctl(dev->device_handle, HIDIOCGRDESC, &rpt_desc);
    if (res < 0) {
        perror("HIDIOCGRDESC");
    } else {
        /* Determine if this device uses numbered reports. */
        dev->uses_numbered_reports =
            uses_numbered_reports(rpt_desc.value,
                                  rpt_desc.size);
    }

    return dev;
}
else {
    /* Unable to open any devices. */
    free(dev);
    return NULL;
}

Best Answer

I gave up running around trying to figure out some other means of doing it than udev rules, and instead just learned a bit about udev and wrote a flippin' rule. The following line was placed in a .rules file (I named mine 99-hidraw-permissions.rules) located under /etc/udev/rules.d.

KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="plugdev"

Basically this assigns all devices coming out of the hidraw subsystem in the kernel to the group plugdev and sets the permissions to r/w r/w r (for root [the default owner], plugdev, and everyone else respectively). With myself added to the plugdev group, everything's dandy.

Not quite as brain melting as I'd expected. Udev rules actually seem pretty straightforward... I mean, they look like they can get ridiculous if you're dealing with individual product IDs and whatnot, but they seem pretty damn tame for what they do.

Related Solutions

Why are network interfaces not in /dev like other devices

On many devices, the main operations are to send bytes from the computer to a peripheral, or to receive bytes from a peripheral on the computer. Such devices are similar to pipes and work well as character devices. For operations that aren't reading and writing (such as flow control on a serial line), the device provides ad-hoc commands called ioctl.

Some devices are very much like regular files: they're made of a finite number of bytes, and what you write at a given position can later be read from the same position. These devices are called block devices.

Network interfaces are more complex: what they read and write is not bytes but packets. While it would still be possible to use the usual interface with read and write, it would be awkward: presumably each call to write would send a packet, and each call to read would receive a packet (and if the buffer is too small for the packet to fit, the packet would be lost).

Network interfaces could exist as devices providing only ioctl. In fact, this is what some unix variants do, but not Linux. There is some advantage to this approach; for example, on Linux, network interfaces could leverage udev. But the advantages are limited, which is why it hasn't been done.

Most network-related applications don't care about individual network interfaces, they work at a higher level. For example, a web browser wants to make TCP connections, and a web server wants to listen for TCP connections. For this purpose, what would be useful is devices for high-level network protocols, e.g.

{ echo $'GET http://www.google.com/ HTTP/1.0\r';
  echo $'Host: www.google.com\r';
  echo $'\r' >&0; cat; } <>/dev/tcp/www.google.com/80

In fact ksh and bash provide such an interface for TCP and UDP clients. In general, however, network applications are more complex than file-accessing applications. While most data exchanges are conducted with calls analogous to read and write, establishing the connection requires more information than just a file name. For example, listening for TCP connections takes two steps: one to be performed when the server starts listening, and one to be performed each time a client connects. Such extra steps don't fit well into the file API, which is the main reason why networking has its own API.

Another class of devices that typically doesn't have entries in /dev on Linux (but does on some other unix variants) is video adapters. In principle, simple video adapters could be exposed as framebuffer devices, which could be block devices made of blocks representing the color of each pixel. Accelerated video adapters could be represented as character devices onto which applications send commands. Here, the drawback of the device interface is that it's slow: the displaying application (in practice, an X server) would need to make kernel calls whenever displaying anything. What happens instead is that the X server mostly writes directly to the memory of the video adapter, because it's faster.

Allow non-root user to read/write /dev files

How udev rules are structured

For devices falling into subsystem tty, you can set their group as follows:

SUBSYSTEM=="tty", GROUP="dialout"

Note that, just like in common programming, == is a test for equality while = is an assignment. So, the above statement translates to "if SUBSYSTEM=="tty" then assign GROUP="dialout". A statement may have multiple tests, which are and-ed together, and multiple assignments.

If you wanted to change the read-write-execute permissions, then assign MODE instead of GROUP where MODE follows the usual Unix octal notation, e.g. MODE="0660" gives the owner and the group read-write permissions. man udev has all the details.

You can find many examples of such rules in /lib/udev/rules.d/91-permissions.rules

How to add a udev rule to your system

Once you have settled on what you want your rule to be, it is simple enough to add it. On a debian-derived system, go to the directory /etc/udev/rules.d and create a file. Files are run in sort-order. So, to make your rules file the last to be read, overriding earlier ones, try a name like 99-instruments.rules. Then put your rules in that file, one per line. (If need by, lines can be extended by putting a backslash at the end of the line, just like in shell.)

So, if you want to change group and permissions on tty devices, your file /etc/udev/rules.d/99-instruments.rules could consist of the single line:

SUBSYSTEM=="tty", GROUP="dialout", MODE="0660"

To assure that your new file itself has the usual permissions:

sudo chown root:root /etc/udev/rules.d/99-instruments.rules
sudo chmod 0644 /etc/udev/rules.d/99-instruments.rules

After you have created your file, udevd may automatically read it. If not, you can force it re-read its files with:

udevadm control --reload-rules

More on how udev classifies devices

If you want to get finer control over which devices respond to which rules, you can learn more about how udev sees your devices by perusing /sys/. At this moment, I don't have access to a machine with a ttyUSB or an HPIB, so let's make an example of disk sda. Run:

udevadm info --attribute-walk --path=/sys/block/sda

This gives a lot of information that looks like:

. . . .
KERNEL=="sda"
SUBSYSTEM=="block"
DRIVER==""
ATTR{range}=="16"
ATTR{ext_range}=="256"
ATTR{removable}=="0"
. . . .

These lines are all in the form suitable for using as if clauses in rules. So, for example, to change the ownership on all block devices that are marked as non-removable, we would use the rule:

SUBSYSTEM=="block", ATTR{removable}=="0", OWNER=john1024

With information from udevadm, one can develop rules that can target specifically the devices of interest.