Should I use jail?

A.J. 'Fonz' van Werven freebsd at skysmurf.nl
Mon Feb 17 18:39:37 UTC 2014


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.

AvW

Ad (*): I use NIS to share uids/gids between jails (and the host).

-- 
I'm not completely useless, I can be used as a bad example.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20140217/595e617a/attachment.sig>


More information about the freebsd-stable mailing list