Bug 213375

Summary: cap_copy_*() backwards and forwards compatibility
Product: Tools Reporter: Andrew G. Morgan (morgan)
Component: libcapAssignee: Andrew G. Morgan (morgan)
Status: RESOLVED CODE_FIX    
Severity: normal    
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: n/a Subsystem:
Regression: No Bisected commit-id:

Description Andrew G. Morgan 2021-06-09 02:58:55 UTC 
The cap_copy_int() function is quite permissive when reading externalized capabilities, but the cap_copy_ext() hard codes the size. It seems as if they could both be more flexible when the raised capabilities are all in the lower bits.

That is, when libcap (v1) only supported 32-bit capabilities, it exported them with 3*4 byte vectors. These external vectors could be imported when applied on 64-bit capable systems. But the other direction (exported from 64-bit) was not supported even when only the first 32-capability bits were being used.

While we are not yet close to expanding beyond 64 bits, I'd like to avoid this issue recurring.
Comment 1 Andrew G. Morgan 2021-06-09 05:12:15 UTC 
It turns out that the Go functions cap.Import() and cap.Export() already work this way.

That being said, in case anyone is using the libcap C functions and depends on their current behavior, I'm going to preserve cap_copy_ext() behavior for current external representations. All of the libcap/cap (Go) and libcap (C) functions interoperate on external data.