Allow the location of capabilities.conf to be configured.

[brooks]

Summary

Also allow a per-abi syscall prefix to be configured with the
abi_func_prefix syscalls.conf variable and check syscalls against
entries in capabilities.conf with and without the prefix amended.

Take advantage of these two features to allow use shared capabilities.conf
between the default syscall vector and the freebsd32 compatability
layer. We've been inconsistent about keeping the two in sync as
evidenced by the bugs fixed in r340294. This eliminates that problem
going forward.

[brooks]

Note, with rS340294 already applied make sysent makes no changes after this change.

[kib]

Does it mean that if we have both foo and freebsd32_foo, then we cannot selectively enable only one of them for cap mode ?

[emaste]

In D17932#383019, @kib wrote:

Does it mean that if we have both foo and freebsd32_foo, then we cannot selectively enable only one of them for cap mode ?

I think that's probably fine, although maybe we should generate a warning or error if both exist?

[brooks]

In D17932#383019, @kib wrote:

Does it mean that if we have both foo and freebsd32_foo, then we cannot selectively enable only one of them for cap mode ?

Yes. I can't imagine a situation where we'd want to do that.

[brooks]

In D17932#383198, @emaste wrote:

In D17932#383019, @kib wrote:

Does it mean that if we have both foo and freebsd32_foo, then we cannot selectively enable only one of them for cap mode ?

I think that's probably fine, although maybe we should generate a warning or error if both exist?

That would fail today with mknodat/freebsd32_mknodat.

[brooks]

In D17932#383618, @brooks wrote:

In D17932#383019, @kib wrote:

Does it mean that if we have both foo and freebsd32_foo, then we cannot selectively enable only one of them for cap mode ?

Yes. I can't imagine a situation where we'd want to do that.

I can imagine a situation where we have COMPAT# and regular versions and want to handle them differently, but this change doesn't effect that. foo and freebsd32_foo being different would defiantly be a bug if there wasn't an analog in the default syscall table.

In any case, you can always enable a syscall for capabilities and then reject calls in CAP_MODE from the handler.