When using the Python binding for selinux to run restorecon recursively on a directory, the policy restricting the Python process requires the selinux_validate_context permission in addition to the explicit relabel statements, which does not seem right.

The Python code is simple; something like:

import selinux
selinux.restorecon('/path/to/dir', recursive=True)

The selinux label is celery_t and it has these allow statements in its policy:

allow celery_t httpd_sys_rw_content_t:dir relabelto;
allow celery_t httpd_sys_rw_content_t:file relabelto;
allow celery_t httpd_sys_rw_content_t:lnk_file relabelto;
allow celery_t pulp_var_cache_t:dir relabelfrom;
allow celery_t pulp_var_cache_t:file relabelfrom;
allow celery_t pulp_var_cache_t:lnk_file relabelfrom;

The strange thing is that SELinux also requires this statement:

selinux_validate_context(celery_t)

The description on that refpol statement is that statement: "Allows caller to validate security contexts".

Why is that necessary? Is this a bug in the restorecon() call of the selinux python binding?

If I omit the selinux_validate_context() permissions, I receive these AVC denials:

type=AVC msg=audit(1476979237.205:84012): avc:  denied  { read write } for  pid=31476 comm="celery" name="context" dev="selinuxfs" ino=5 scontext=system_u:system_r:celery_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=file permissive=0
type=AVC msg=audit(1476979237.205:84013): avc:  denied  { read write } for  pid=31476 comm="celery" name="context" dev="selinuxfs" ino=5 scontext=system_u:system_r:celery_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=file permissive=0