Date: Thu, 09 May 2013 15:24:46 -0500 From: Joshua Isom <jrisom@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: priv_check/make_dev/devfs.rules: What is preventing a device to show up in a jail? Message-ID: <518C060E.8040301@gmail.com> In-Reply-To: <20130509110718.0000528e@unknown> References: <20130509110718.0000528e@unknown>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?518C060E.8040301>