capng_get_caps_process vs sandbox

[dagrh]

Hi,
I've got a heavily sandbox'd daemon that runs something like:
a) Sandbox
b) Create more threads
c) Do stuff in threads

The sandbox includes a mount namespace setup where it doesn't have /proc.
capng_get_caps_process calls get_bounding_set which reads /proc/.../state - which fails.
That's not a problem with yee oldee libcaps, it only uses capget.
So now I have a problem how to setup each thread; the current guess is to do a capng_save_state before the sandboxing, and then do a restore state somewhere in each thread.
Which is kind of OK except for restore_state freeing stuff; so I'm going to have to do a dance of restore_state/save_state to keep a copy.

It feels like there should be a better way.

[stevegrubb]

I would agree. The issue is that getcap does not provide the bounding set:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/capability.c?h=v5.4#n148

It only deals with the 3 normal sets. Ye olde libcap leaves the bounding set up to the individual to work out. It does not treat it as an equal component to capabilities. I suppose a fallback for this could be created which iterates over prctl testing each bit with PR_CAPBSET_READ. This would take some 37 syscalls (today) to work out...which is why we try to use /proc/<pid>/status. But at least this will get the right answer.

[dagrh]

What I've ended up with is:
https://gitlab.com/virtio-fs/qemu/commit/a45a4abfd73c18e254e4ebffacb41ed300a741d8

which isn't pretty but seems to work.

[stevegrubb]

Commit a074f1b should fix this.