fix RESCUE: include lib/libjail/jail.c in librescue if necessary

cap_jail.c: improve allocation and error handling in service command

cap_sysctl.c: resolve names to mibs when limits are set.

• rename cap_jail_get -> cap_jail and system.cap_jail_get -> system.cap_jail
• cap_jail:
  • fix copyright
  • add man page
• cap_jail.c:
  • style(9) changes
  • use dnvlist_* in service command
  • split nvlist -> iov function in two: nvl_to_iov_s is used by the service and makes sure there is space before memcpy
• jls.c: use caph_enter_casper
• cap_sysctl.c: style
• cap_sysclt.3: reference sysctl(3)

WOW! Thank you for working on that!

I removed to kernel changes and used libcasper to obtain sysctl and jail_get functionality needed for jls(1).

Please use libcasper(3) to obtain valid sysctl.

caph_cache_catpages(3) before cap_enter(2)

connectat/bindat description updated in rS333119

Had a quick skim, but LGTM.

Thank you, I will try to review soon and have added some other Capsicum folks.

In D8753#258283, @emaste wrote:

From in-person working group session, a suggestion to rename libcasper.h to libcasper.h.in and run unifdef on it during install.

% cat example.h.in
// example header file
#ifdef WITH_CASPER
// casper version
#else
// non-casper version
#endif

% unifdef -UWITH_CASPER -o example.h example.h.in
% cat example.h                                  
// example header file
// non-casper version

% unifdef -DWITH_CASPER -o example.h example.h.in
% cat example.h                                  
// example header file
// casper version

From in-person working group session, a suggestion to rename libcasper.h to libcasper.h.in and run unifdef on it during install.

As discussed with emaste@ I commited the changes regarding the stabilization of the ifdefs name in separate commit (r323866). This should make diff a little bit smaller.

Update with -U9999.

Would you please upload a diff with full context (-U9999)? Thanks.

Update to new libcasper version.

Hi Guys :)

Maybe what I'm about to say is blasphemy in our circles, but it looks like this tries to solve a problem that an object oriented programming language with virtual functions (C++) could easily solve. libcasper's header file would provide declarations for abstract base classes for all sorts of handles. Then there are two implementations of these classes: one that acts as a no-op and one that is actually built on top of Capsicum. That way there is no need to resort to linker tricks.

I don't really much like this approach, plus there is a high risk to have libcaspermock and libcasper out of sync

The changes proposed seem ok, in so long as it addresses the regression I reported on svn-src-all@.

@ngie Thoughts? I'd like to commit this and move on to other things, so review/approval is highly appreciated.

In D8753#181465, @oshogbo wrote:

The only situation I can think of where you would like to have two libraries is when you would install something from ports which you don't want to use Casper and your base system is using Casper.

The behavior of few functions are a little bit different libcasper and libcaspermock but this still could be merged somehow.
The only situation I can think of where you would like to have two libraries is when you would install something from ports which you don't want to use Casper and your base system is using Casper.