Automatic service jails - review request

Hi,

I implemented a functionality which allows to automatically put rc.d  
services into jails. They inherit the same filesystem, and maybe the  
same network / jailed sysvipc / ..., so it's not the same isolation as  
a manual jail with a separate filesystem, but at least you can  
restrict access to sysvpic, parts of net, ..., and unrelated processes  
automatically (1-2 config lines in rc.conf). The included man-page  
change contains more info. I'm intentionally a bit less verbose here,  
as this is also a test to see if the man page is good enough to  
describe this.

I have put up some reviews in Phabricator:
  - https://reviews.freebsd.org/D40369
    -> Extend /usr/bin/service with the possibility to set ENV vars
    This is a pre-req for the functionality.
  - https://reviews.freebsd.org/D40370
    -> The implementation.
  - https://reviews.freebsd.org/D40371
    -> Additional config for /some/ basesystem services (e.g. allow  
network access for syslogd).

The /usr/bin/service change is something which also helps in  
developing/debugging rc.d scripts in general. I think it could be  
committed before the branch of 14-stable (and as such would then allow  
an easy MFC of the implementation later).

The other two reviews may need some revisions (and the 3rd may benefit  
from further changes to services (which can come in later) I don't  
have in use myself or haven't had the time to have a look at it), but  
I have those changes running since some years and I should try to get  
them out the door. Peer review/pressure may help here... :)

Note, this is the second implmementation which uses an env var to  
track state (much simpler code than the first implementation), whereas  
the first implementation tried to use different commands  
("startjailed/stopjailed") to track state.

It would be nice if some people with insight into /etc/rc would have a  
look at D40369 and D40370, and everyone interested in this  
functionality into the man pages and whatever kind of area they can  
provide some insight into.

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF