4

Using matchpathcon against a file (e.g. /usr/lib64/gconv/gconv-modules.cache) I get:

/usr/lib64/gconv/gconv-modules.cache  system_u:object_r:lib_t:s0

However:

# ls -alZ /usr/lib64/gconv/gconv-modules.cache
-rw-r--r--. root root unconfined_u:object_r:lib_t:s0

So it would appear that the file does NOT have the proper context (mismatched user portion). However, when running restorecon -v the file is not changed.

I can do this:

# chcon -t httpd_sys_content_t /usr/lib64/gconv/gconv-modules.cache
# ls -alZ /usr/lib64/gconv/gconv-modules.cache
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0
# restorecon -v /usr/lib64/gconv/gconv-modules.cache
unconfined_u:object_r:httpd_sys_content_t:s0 -> unconfined_t:object_r:lib_t:s0

So restorecon seems to only update the SELinux type of a file but not the user context. Is this a bug or is there an explanation for this behavior? I am thinking it may be a bug because the documentation (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html) shows a restorecon on a file with mismatched user context and it is changed from unconfined_u->system_u as expected.

OS: RedHat 7.3
SELinux: 3.13.1-102.el7_3.16

3

After opening a support case I see that I was mislead by the Red Hat documentation and should have read the man page more closely:

# man restorecon
...
If  a  file  object  does not have a context, restorecon will write the
default context to the file object's extended  attributes.  **If  a  file
object  has  a context, restorecon will only modify the type portion of
the security context.  The -F option will force a  replacement  of  the
entire context.**
...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.