Description of problem: We already label the old location of the default cracklib dictionary (/usr/lib(64)?/cracklib_dict.pwd) as crack_db_t. If we want to take advantage of cracklib's ability to read compressed dictionaries, we need to ensure that the compressed version of the dictionary (/usr/lib(64)?/cracklib_dict.pwd.gz) has the same label. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.12.1-47.fc19.noarch How reproducible: Always Steps to Reproduce: matchpathcon /usr/share/cracklib/pw_dict.pwd.gz /usr/share/cracklib/pw_dict.pwd /usr/lib64/cracklib_dict.pwd.gz /usr/lib64/cracklib_dict.pwd /usr/lib/cracklib_dict.pwd.gz /usr/lib/cracklib_dict.pwd Actual results: /usr/share/cracklib/pw_dict.pwd.gz system_u:object_r:crack_db_t:s0 /usr/share/cracklib/pw_dict.pwd system_u:object_r:crack_db_t:s0 /usr/lib64/cracklib_dict.pwd.gz system_u:object_r:crack_db_t:s0 /usr/lib64/cracklib_dict.pwd system_u:object_r:lib_t:s0 /usr/lib/cracklib_dict.pwd.gz system_u:object_r:crack_db_t:s0 /usr/lib/cracklib_dict.pwd system_u:object_r:crack_db_t:s0 Expected results: They should all have the same label, I think.
Wow, I even got myself confused there. It's /usr/lib(64)?/cracklib_dict.pwd, which is often a symlink to /usr/share/cracklib/pw_dict.pwd now.
So it should be ok. # matchpathcon /usr/share/cracklib/pw_dict.pwd /usr/share/cracklib/pw_dict.pwd system_u:object_r:crack_db_t:s0
That one's fine. It's /usr/lib64/cracklib_dict.pwd which is labeled lib_t on my system, I'm guessing because the context configuration doesn't match if it's a symlink.
Yes we are only labeling files if they match, and everything is allowed to read lib_t symlinks (almost) so this should not be a bug. ls -lZ /usr/share/cracklib/pw_dict.pwd.gz -rw-r--r--. root root system_u:object_r:crack_db_t:s0 /usr/share/cracklib/pw_dict.pwd.gz