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.


_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Reply via email to