[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libcap vs libcap-ng mess
From: |
Paolo Bonzini |
Subject: |
Re: libcap vs libcap-ng mess |
Date: |
Mon, 2 Dec 2019 11:33:29 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 |
On 02/12/19 11:07, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (address@hidden) wrote:
>> Il ven 29 nov 2019, 19:54 Dr. David Alan Gilbert <address@hidden> 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).
"In the middle of sandboxing" would have been a more precise suggestion.
In the virtio-9p proxy I set up the state right after the sandboxing
capng_apply, so that there is no need to do capng_get_caps_process (the
libcap virtio-9p also used cap_get_proc). So you could capng_save_state
there.
Paolo