* Paolo Bonzini (pbonz...@redhat.com) wrote: > 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?
Because in our sandbox we don't have /proc and capng_get_caps_process tries to read /proc/.../status and fails. The old libcap code doesn't use /proc, it just uses capget (which the new one also uses). > 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. Hmm yes, that's easier. > 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. OK, thanks. Dave > Paolo -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
