priv_check/make_dev/devfs.rules: What is preventing a device to show up in a jail?

[Joshua Isom]

If you're just doing virtualization and not worrying about security, 
there's a simple test.  Don't set "devfs_enable" in rc.conf, and instead 
add a devfs line to the jail's fstab file.  It should give full access 
to everything in the host's /dev.

On 5/9/2013 4:07 AM, Alexander Leidinger wrote:
> Hi,
>
> big picture: I want to get access to my USB DVB device in a jail. First
> I explain what works (to show what I already know in this regard), then
> I explain what doesn't work (where I seem to lack some knowledge).
>
> What I did so far:
> I already patched my kernel to give access to /dev/io and /dev/dri in a
> jail to have X1 up and running in a jail (works since some years):
>   - changed PRIV_DRIVER to PRIV_DRI_DRIVER (new in my kernel)
>     for the priv_check() for /dev/dri
>   - added cases PRIV_IO and PRIV_DRI_DRIVER to sys/kern/kern_jail.c
>     which allow access if a specific allow.xxx flag is set for the jail
>   - added the following lines to devfs.rules in a x11-jail specific
>     section (plus some more devices):
> ---snip---
> add path agpgart unhide
> add path dri unhide
> add path 'dri*' unhide
> add path nvidiactl unhide
> add path 'nvidia*' unhide
> add path io unhide
> add path mem unhide
> ---snip---
>
> Patches at http://www.Leidinger.net/FreeBSD/current-patches/0_jail.diff
>
> Result so far:
>   - I see the io/mem/nvidia* devices (when I had a Radeon card which
>     used /dev/dri, I was also seeing the devices in the /dev/dri/
>     directory)
>   - I have X11 running in a jail (some config stuff skipped in the
>     above list).
>
> My problem:
> I try now to get the device nodes which are created by
> multimedia/cuse4bsd-kmod + mltimedia/webcamd visible
> in a jail, but they only show up in the jail-host, not in the jail
> itself.
>
> I patched the priv_check()s in cuse4bsd-kmod to use PRIV_DRI_DRIVER
> (because it is already available in my kernel and allowed in the jail
> where I test this; I expect this is necessary in case I want to run
> webcamd in the jail instead on the host system) and have the following
> entries in devfs.rules:
> ---snip---
> [devfsrules_unhide_cuse=13]
> add path cuse unhide
> add path video unhide
> add path 'video*' unhide
> add path dvb unhide
> add path 'dvb*' unhide
> add path input unhide
> add path 'input*' unhide
> ---snip---
>
> I also tried with:
> ---snip---
> add path 'dvb/*' unhide
> add path 'dvb/adapter0/*' unhide
> ---snip---
> (I was as desperate to even reboot the entire host system after
> changing the rules to make sure I didn't forget to run something which
> should be run before.)
>
> When starting webcamd in the host system (to rule out some other
> interactions if I would start it in the jail), i can see in the jail:
> ---snip---
> /dev/cuse
> /dev/dvb/
> /dev/input/
> /dev/input/event0
> ---snip---
>
> In the host system I have additionally:
> ---snip---
> /dev/dvb/adapter0/ca0
> /dev/dvb/adapter0/demux0
> /dev/dvb/adapter0/dvr0
> /dev/dvb/adapter0/frontend0
> ---snip---
>
> I would expect to see at least the /dev/dvb/adapter0, if not all of
> them in the jail itself.
>
> Is there something to the devfs.rules syntax or priv_check() or
> make_dev()/make_dev_cred() I don't know/understand which is involved
> when subdirectories of subdirectories in /dev are involved?
>
> How can I debug this (where to look, what to look for, ...)?
>
> Bye,
> Alexander.
>