Should I use jail?

Ian Lepore ian at FreeBSD.org
Mon Feb 17 18:53:49 UTC 2014


On Mon, 2014-02-17 at 19:39 +0100, A.J. 'Fonz' van Werven wrote:
> Phil Regnauld wrote:
> 
> >>> For what it's worth I never, ever run any service without running it in
> >>> a jail.
> >> 
> >> Smartass comment: if that includes ntpd or a master NIS server, would
> >> you care to divulge how you did that?
> > 
> > I don't know why the NIS server would be any different,
> 
> The problem with NIS (and by extension NFS) is rpcbind, which AFAIK cannot
> run in a jail.
> 
> For jails that are NIS clients(*) I currently have to use a workaround I
> found on the Forums, which is to add
> 
>   service rpcbind forcestop
> 
> to /etc/rc.d/ypbind because otherwise (yp)chsh, (yp)chfn and (yp)passwd
> won't work from the jails.
> 
> > but for services that require access to devices (say, ntpd talking to a
> > GPS over USB), you define new devfs rules to unhide the requisite /dev/
> > entries for the jails running the service. I do this for OpenDNSSEC
> > using a smartcard reader.
> > 
> > Here's a devfs.conf entry to make it possible to access BPF (for tcpdump
> > among other things - but beware of giving access to raw devices this
> > way) and ugen* devices under /dev/
> > 
> > [devfsrules_jail_bpf=5]
> > add include $devfsrules_jail
> > add path 'bpf*' unhide
> > add path 'ugen0.*' unhide
>  
> What do you know: what was intended as a smartass comment that I almost
> refrained from sending in the first place actually elicited a useful
> response. Thank you very much for the suggestion, I'll look into that.
> 
> The main question would be which /dev entry provides (write) access to the
> system clock, if that even goes through a /dev entry to begin with. A
> quick look through /usr/src/sys didn't turn up anything.

ntpd (or anything else running as root) steers the system clock using
the ntp_adjtime(2), defined in sys/timex.h.  There are no devices
involved unless ntpd is also processing a PPS signal, in which case it
uses /dev/pps#.

-- Ian




More information about the freebsd-stable mailing list