Needs Casper bindings

[asomers]

Capsicum's model is to block access to global namespaces. But important operations like gethostbynbame and sysctlbyname operate on global namespaces only. So to sandbox that, Capsicum uses the technique of privilege separation. Through libcasper(3) it forks child processes to deal with stuff like that. We should provide bindings for libcasper and the most important casper services. I've already got a start on this.

[dlrobertson]

From johalun/sysctl-rs#59 (comment):

Well, nobody will ever use libcasper without using capsicum. There are, however, plenty of use cases for capsicum that don't require libcasper. But shorn of its services, libcasper is pretty small. IMHO it doesn't require a standalone crate. What about adding it to capsicum-rs, but gated by a feature flag?

Thanks for the explanation. I've only ever used capsicum (I recognize that that's a bit weird 😆). I think a feature flag makes a lot of sense, but it's probably worthwhile to add it to the default-features?

Moving discussion here to avoid cluttering johalun/sysctl-rs#59

[asomers]

I don't think we should put it in default-features, because that will link libcasper.so into applications that don't need it. See #35 for the implementation.

[asomers]

Fixed in #35 .