should this be allowed inside capsicum? check against IN_CAPABILITY_MODE(curthread) or something?

same here

allowed?

only if id = -1?

eventually this might allow setting on a thread, should the if consider that, so that if the following condition is changed/removed, it doesn't block things?

These seem sorted wrong

Why not allow it? It's just a helper and can only restrict the set(s) further. I don't think a check is needed here.

Only if pid == -1, right?

Right.

Yeah, why not follow the same pattern you've used below?

Hmm, this file seems to be mostly unsorted already :( I suppose supporting with another 'c' header is as good as anywhere.

Yep, this helper doesn't need to be aware of capsicum.

These CPU sets refer to a global namespace; these should not be permitted in capability mode at all I think?

This one looks good to me

I think that's out of scope for Capsicum.

This comment will need updating.

I find this check pretty hard to read and understand. Is there some way to refactor it to use a nested if in an outside block conditioned in IN_CAPABILITY_MODE() and possibly a check on level to make it more readable?

Ditto here. I find the complex boolean expression hard to follow, and hence convince myself it is right. Can this become a nested if..?

So something like:

if (IN_CAPABILITY_MODE(td)) {
        if (level ...
                return (ECAPMODE);
}

Then do you think the inner if is more clear as
if (!(level == CPU_LEVEL_WHICH && (which == CPU_WHICH_TID || which == CPU_WHICH_PID) && id == -1))
or
if (level != CPU_LEVEL_WHICH || (which != CPU_WHICH_TID && which != CPU_WHICH_PID) || id != -1)

or even something like

if (level != CPU_LEVEL_WHICH)
        return (ECAPMODE);
if (which != CPU_WHICH_TID && which != CPU_WHICH_PID)
        return (ECAPMODE);
if (id != -1)
        return (ECAPMODE);

Yes, this sounds good (one big outside check for IN_CAPABILITY_MODE(td), and then the sequence of if() checks). It's now much more obvious to me what the policy is.

Possibly should be "caller's" or "callers'" (depending on whether you intend the plural or not).

Do be sure to commit generated system-call files in a seperate commit (as @kib has rightly reminded me regarding recent commits).

Probably better to say "is only allowed to" instead of "may".

This needs to be added to the SEE ALSO section, too.

This is in the wrong place. This list is sorted by category first, then alpha.