From owner-freebsd-hackers@FreeBSD.ORG Thu May 9 20:24:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B5773BA1 for ; Thu, 9 May 2013 20:24:57 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 8303DFDE for ; Thu, 9 May 2013 20:24:57 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id ef5so620582obb.2 for ; Thu, 09 May 2013 13:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=y5TC0+kUhxnFNzmR9WgayMQi1w9QuwYS/XfN9f0GnFk=; b=qM8BtqinO2C0/PUBpMucCcbyMnY7iqpWdiQA63SKXHgAy+agJ7GNxV4frivws7oKyL crWFxNu0SZsAM70hRPBoKiLBfkye1BYCYcJbucMRKegiOlo3CgVf4pXoeInT4cScdCa8 VRWV9wdJ2LvqY/JlhRAX9I9Yo5PD+NxjaDBV0ERtDzwv0+R9I5V+GTlgtVsheYD4jCIt 6BGRSl7oHmd86tMGKW5hQ8pGUAVkHZ9GqXoO+yT2lVftFTjag0wui4VxropXo8pYqZqO JcqC+MoRKKRnnSO5E/7jM+ld/vf+CIByDyCAWwfZlJCiubRRymil0T/YT2VL5klgH1Vd Jz9Q== X-Received: by 10.60.79.131 with SMTP id j3mr5352372oex.71.1368131097164; Thu, 09 May 2013 13:24:57 -0700 (PDT) Received: from [192.168.1.34] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPSA id p9sm4975209oeq.7.2013.05.09.13.24.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 13:24:56 -0700 (PDT) Message-ID: <518C060E.8040301@gmail.com> Date: Thu, 09 May 2013 15:24:46 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: priv_check/make_dev/devfs.rules: What is preventing a device to show up in a jail? References: <20130509110718.0000528e@unknown> In-Reply-To: <20130509110718.0000528e@unknown> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 20:24:57 -0000 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. >