Can you do ldd capsh ? I'm wondering if you are linking dynamically and linking to the older libcap?

In a libcap build tree, which links capsh statically, your command yields this:

$ ldd progs/capsh
$ sudo progs/capsh --drop=cap_mknod  -- -c 'capsh --print'
Current: =eip
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
Ambient set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root)
Guessed mode: UNCERTAIN (0)

That is:

$ ldd progs/capsh
        not a dynamic executable

[The 'i' in my inheritable set is some stupidity with the Linux distribution I'm running.. Please ignore that.]

[root@arch vagrant]# capsh --drop=cap_mknod  -- -c 'capsh --print'
Current: =ep cap_mknod,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63-ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
Ambient set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root)
Guessed mode: UNCERTAIN (0)

[root@arch vagrant]# ldd `which capsh`
	linux-vdso.so.1 (0x00007fff26dbb000)
	libcap.so.2 => /usr/lib/libcap.so.2 (0x00007ff72bbc8000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007ff72ba00000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff72bbf0000)

[root@arch vagrant]# pacman -Q libcap
libcap 2.29-1

[root@arch vagrant]# pacman -Ql libcap | grep libcap.so
libcap /usr/lib/libcap.so
libcap /usr/lib/libcap.so.2
libcap /usr/lib/libcap.so.2.29

[root@arch vagrant]# ls -la /usr/lib/libcap.so*
lrwxrwxrwx 1 root root    11 Dec 25 23:34 /usr/lib/libcap.so -> libcap.so.2
lrwxrwxrwx 1 root root    14 Dec 25 23:34 /usr/lib/libcap.so.2 -> libcap.so.2.29
-rw-r--r-- 1 root root 26544 Dec 25 23:34 /usr/lib/libcap.so.2.29

Also, I tried to compile the latest libcap version and test with that (on a different system, F31) with following results:

$ ldd progs/capsh
	not a dynamic executable

$ sudo progs/capsh --drop=cap_mknod  -- -c '$PWD/progs/capsh --print'
Current: =ep cap_mknod-ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
Ambient set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root)
Guessed mode: UNCERTAIN (0)

Yes, more coffee needed.

I guess I was testing with the latest tree. It would appear that something in 2.29 was still getting confused about what "all" meant. The decode of the bits still appears to assume all was the full 64-bits.

libcap-2.30 appears to not have that issue. Do you have a reason not to upgrade to 2.30?

I believe it is something in here that fixed it:

https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=f1f62a748d7c67361e91e32d26abafbfb03eeee4

Ah, thank you, now it makes sense. I got confused by seeing the dropped capability in the fixed version as well, but only just now I noticed the '-ep' suffix, which actually lowers the preceding capabilities.

In that case the issue seems to be indeed resolved by switching to v2.30. Thank you!