I suppose so (not tested yet), you can find an example in this docker run script:
docker run
-t --rm
–privileged
-v $XSOCK:$XSOCK
-v /etc/localtime:/etc/localtime:ro
-v /dev/sr0:/dev/sr0
-v /dev/cdrom:/dev/cdrom
-v $RIPS:/rips
–name handbrake marvambass/handbrake &
As mentioned in the comments by Luca, the --privileged flag is required (docker run):
by default, most potentially dangerous kernel capabilities are dropped; including cap_sys_admin (which is required to mount filesystems). However, the --privileged flag will allow it to run.
The --privileged flag gives all capabilities to the container, and it also lifts all the limitations enforced by the device cgroup controller.
In other words, the container can then do almost everything that the host can do.
This flag exists to allow special use-cases, like running Docker within Docker.
As Vincent Demeester mentions in the comments, there is also the --device option:
It is often necessary to directly expose devices to a container. The --device option enables that.
For example, a specific block storage device or loop device or audio device can be added to an otherwise unprivileged container (without the --privileged flag) and have the application directly access it.
By default, the container will be able to read, write and mknod these devices. This can be overridden using a third :rwm set of options to each --device flag
Note: --device cannot be safely used with ephemeral devices. Block devices that may be removed should not be added to untrusted containers with --device.
As seen in issue 10637, some devices can change their node names. See issue 8826
If you launch the Docker daemon with the lxc backend, you should be able to use --lxc-conf=lxc.cgroup.devices.allow = c 189:* rwm to allow your container to access all devices of that group, and then use a volume -v /dev/bus/usb/:/dev/bus/usb/ to access all USB devices.