On 09/18/2018 12:12 AM, John Ferlan wrote:
> [...]
> >> +
>
> After seeing it in use in patch 19 and thinking about it for a very
> short period of time, would it make more sense to store @lock somewhere
> so that virSecurityManagerMetadataUnlock doesn't fail because the
> virSecurityManagerNewLoc
On 09/17/2018 11:14 PM, John Ferlan wrote:
>
>
> On 09/10/2018 05:36 AM, Michal Privoznik wrote:
>> Two new APIs are added so that security driver can lock and
>> unlock paths it wishes to touch. These APIs are not for other
>> drivers to call but security drivers (DAC and SELinux). That is
>> th
[...]
VIR_FROM_THIS VIR_FROM_SECURITY
>
> VIR_LOG_INIT("security.security_manager");
>
> +virMutex lockManagerMutex = VIR_MUTEX_INITIALIZER;
> +
> struct _virSecurityManager {
> virObjectLockable parent;
>
> @@ -43,6 +47,7 @@ struct _virSecurityManager {
> void *privateData;
>
On 09/10/2018 05:36 AM, Michal Privoznik wrote:
> Two new APIs are added so that security driver can lock and
> unlock paths it wishes to touch. These APIs are not for other
> drivers to call but security drivers (DAC and SELinux). That is
> the reason these APIs are not exposed through our
> li
On 09/10/2018 02:19 PM, Bjoern Walk wrote:
> Michal Privoznik [2018-09-10, 11:36AM +0200]:
>> +int
>> +virSecurityManagerMetadataLock(virSecurityManagerPtr mgr,
>> + const char * const *paths,
>> + size_t npaths)
>> +{
>> +virLockMana
Michal Privoznik [2018-09-10, 11:36AM +0200]:
> +int
> +virSecurityManagerMetadataLock(virSecurityManagerPtr mgr,
> + const char * const *paths,
> + size_t npaths)
> +{
> +virLockManagerPtr lock;
> +virTimeBackOffVar timebackoff;
Two new APIs are added so that security driver can lock and
unlock paths it wishes to touch. These APIs are not for other
drivers to call but security drivers (DAC and SELinux). That is
the reason these APIs are not exposed through our
libvirt_private.syms file.
Three interesting things happen in
