/dev/vchiq is inaccessible for unprivileged user

Bug #1533265 reported by Renat on 2016-01-12
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description

This bug is somewhat related to https://bugs.launchpad.net/snappy/+bug/1500755

After firmware upgrade /dev/vchiq device appears but has crw------- 1 root root access rights.

Because of that, a snap running from an unprivileged user cannot access the device even after hw-assign applied to that snap.

Michael Vogt (mvo) on 2016-04-27
Changed in snappy:
status: New → Confirmed
importance: Undecided → Wishlist
Jamie Bennett (jamiebennett) wrote :

I believe this is a blocker for some use cases so increasing the importance accordingly.

Changed in snappy:
importance: Wishlist → Medium
Michael Vogt (mvo) on 2016-04-30
Changed in snappy:
importance: Medium → High
Oliver Grawert (ogra) wrote :

i fear we need to allow shipping of udev rules in the kernel snap for this ...

Jamie Strandboge (jdstrand) wrote :

Note also that in snappy 16, hw-assign is no more so there is no way to assign this device to a snap at this time. What is this device?

tags: added: snapd-interface

RPI specific device. Is required for h/w decoding at least, may be for something else as well.

Jamie Strandboge (jdstrand) wrote :

IMHO what this needs is for the gadget snap specification to be finalized since it is meant to handle things such as this. Once that is done, we can see what type of interface(s) could be developed to handle these sorts of accesses without gadget snap involvement (ie, in 15.04 hw-assign was created to unblock people, then the gadget spec was created later. For 16 I think it wise to go the other way around). AIUI, the gadget snap spec will be discussed in the coming weeks.

Zygmunt Krynicki (zyga) wrote :

I think that despite gadget snap design this should be a proper first class interface. The rationale for that is that videocore APIs are well-defined (just like pulse or network manager) and are actually an interesting target for developers to use.

I would imagine a videocore interface granting:
 - access to proprietary IMAX blobs, shared libraries and executables shipped by the kernel stap (akin to the content sharing interface or the GL interface)
 - access to various /dev/ nodes specific to videocore

This would allow people to take advantage of raspberry pi camera (and perhaps display) for interesting vertical applications.

Alistair Buxton (a-j-buxton) wrote :

With this interface you can use Qt on EGLFS, which allows you to run fullscreen QT apps without a desktop environment, and with accelerated graphics. This is very useful for embedded stuff. The only other easy way to do this on the Pi is boot2qt, which is a commercial product based on Tizen.

Penk Chen (penk) wrote :

I've attached the log of running oxide-digitalsignage snap in devmode for reference. It's using qmlscene with EGLFS plugin (eglfs_brcm backend on RPi2):


Note the "failed to open vchiq instance" error at the end, it works after "sudo chmod a+rw /dev/vchiq".

Penk Chen (penk) wrote :

@penk apparently /dev/vchiq can be accessed in a confined app by connecting to the opengl interface:


You would still need to run it as root, but I think that is fine as you are using EGLFS, which is the windowing system in your case (you are taking full control of the display).

FTR, ACLs to devices can relieve the need to run programs as root or to change device permissions, but currently these are not supported by the core image. See bug lp: #1646144.

Jamie Strandboge (jdstrand) wrote :

There is a design proposal for this that is undergoing review: https://forum.snapcraft.io/t/snappy-users-and-groups-take-2/1461

Changed in snappy:
status: Confirmed → Triaged
affects: snappy → snapd
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers