Il ven 29 nov 2019, 19:54 Dr. David Alan Gilbert <dgilbert@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