Il ven 29 nov 2019, 19:54 Dr. David Alan Gilbert <dgilb...@redhat.com> ha scritto:
> > Yes, it's per thread. The state can be built from > > capng_clear/capng_get_caps_process + capng_update, and left in there > > forever. There is also capng_save_state/capng_restore_state which, as > > far as I can see from the sources, can be used across threads. > > So, I think what you're saying is I need to: > a) Before we sandbox do the capng_get_caps_process > Why not after sandboxing? If the code is in any way similar to the 9p proxy, you have two states, "sandboxed with capabilities" and "sandboxed without capabilities". The former (permitted=effective) is what you get after setresuid/setresgid, the other can be computed after sandboxing and saved using capng_save_state. The FSETID capability can be updated explicitly before/after capng_apply. b) Before we start a new thread do a capng_save_state and restore it > in the thread > Or just save after (a), and restore always before capng_apply. a) This code is very local - it does a drop FSETID, a write, restore > FSETID > b) I'm not sure but I suspect it's used only in the non-uid=0 case; > the whole thing is just a hack to cause setuid/setgid to be dropped > in the case where it's written by a process that doesn't have FSETID > (hmm I guess if the guest was root but didn't have fsetid then it would > be 0?) > Yes it would. For uid!=0 the kernel clears the effective capabilities so it shouldn't need to do anything, unless virtiodsd restores capabilities after setresuid/setresgid. But are you suggesting I need to change something other than the > effective caps in that case? > No, only the effective caps. Paolo
