When i start a docker container, the runc will call selinux_setprocattr to set the exec_sid before start the container. Meanwhile if i use "semodule -i" to load a policy pp, the old sidtab will be shutdown before switch to the new sidtab, and cause sidtab_context_to_sid failed with the errno -NOMEM. Error message: Dec 14 09:18:18 wuwenming_vudfua_0 docker: time="2017-12-14T09:18:18.549862564+08:00" level=error msg="Handler for GET /v1.23/containers/192.168.0.2:9082/dfs_d:V100R013C11SPC000BCD2/json returned error: No such container: 192.168.0.2:9082/dfs_d:V100R013C11SPC000BCD2" Dec 14 09:18:18 wuwenming_vudfua_0 kernel: [ 48.463179] SELinux: security_context_to_sid(system_u:object_r:svirt_sandbox_file_t:s0:c290,c371) failed for (dev overlay, type overlay) errno=-12 Dec 14 09:18:18 wuwenming_vudfua_0 dbus-daemon: dbus[720]: avc: received policyload notice (seqno=2) Dec 14 09:18:18 wuwenming_vudfua_0 dbus[720]: avc: received policyload notice (seqno=2) runc semodule ->selinux_setprocattr ->security_load_policy ->security_context_to_sid ->sidtab_shutdown(oldsidtab) ->read_lock(&policy_rwlock); ->sidtab_map(&oldsidtab, clone_sid, &newsidtab); ->sidtab_context_to_sid { .... if (s->next_sid == UINT_MAX || s->shutdown) { ret = -ENOMEM; .... } ->read_unlock(&policy_rwlock); ->write_lock_irq(&policy_rwlock); ->"switch to new policydb" ->write_unlock_irq(&policy_rwlock); I wonder that if this is the intention or a bug? If it is the intention, what should the application do when it get -ENOMEM error, to try again? If it is a bug, may the two options below suitable to solve the issue? Option1: use policy_rwlock to protect the "sidtab_shutdown" & "sidtab_map" , load_policy is rarely to be called after system bringing up, so i think it will not impact much on the performance. Option2: Use a temp list to store the sid in oldsidtab after it is shutdown, and deal with it after cloning the major sids from oldsidtab to newsidtab and getting the policy_rwlock. -- Best Regards Li Kun |