Casper new architecture.

[Mariusz Zaborski]

Hello,

I have finally a new version of Casper and I wanted to share with you. [1]
I would like to ask for code review and if possible for some people to
run tests on thier machines.

We decided to change a few things in the Casper architecture:

The first one is that Capser isn't a daemon any more.
Now, after calling the cap_init(3) function Casper will fork from
it's original process, using pdfork(2). Thanks to the changes in r286698
the pdforking will not have any affects to the original process.
Forking from a process has a lot of advantages:
1* We have the same cwd as the original process (so the programmer must be
   aware that if he changed the original process working directory, Casper
   directory will not be changed). But I feel that this is acceptable limitation.
2* The same uid, gid and groups.
3* The same MAC labels.
4* The same descriptor table. This is important for a filesystem service
   because with the old Casper for example, process substitution was not
   possible. When the filesystem service arrives, I want to add some special
   flags that will tell zygote processes to not clear file descriptors. Right
   know for the service, all fd are closed.
5* The same routing table. We can change routing table for process using
   setfib(2).
6* The same umask.
7* The same cpuset(1).
And I probably missed some things on this list.

I decided to remove the libcapsicum library. In my opinion Capser is
connected with capsicum, but Casper can be used also with different sandbox
techniques. Now I would like to refer to it just as libcasper.

Second change is that Casper will not execute any binary files.
Now every services (cap_{dns,grp,etc.}) will be in form of shared library.
I don't see, right now, any advantages on keeping services as executable
binaries. It's a little bit problematic to manage services when we don't have a
global daemon. Services can be in different locations and hard coding one path
(like before /etc/casperd) didn't feel right. On the other hand, adding additional
arguments to cap_init() also don't convince me, because how can the programmer
guess where the administrator will put the Casper services. So in my opinion using
dynamic libraries right know is the best option. Programs need to know the replacement
API (for example cap_gethostbyname which replace gethostbyname) so it needs to
include some library (before just one global library, libcapsicum), so why not
store services inside that library? Thanks to that we also have an implementation of
service and replaced API in one place, so we don't need to jump between libexec
and lib directories.

I hope that you like new architecture of Casper.

Cheers,
Mariusz

[1] https://people.freebsd.org/~oshogbo/casper.patch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20151124/bd87c9de/attachment.bin>