Description of problem: Running dmidecode > dmidecode.txt results in a 0-byte file, even though stdout is normal if one just runs "dmidecode", and even though the above command results in nothing going to stdout. The output doesn't go anywhere, it just vanishes. Version-Release number of selected component (if applicable): dmidecode-2.7-1.23 How reproducible: always Steps to Reproduce: 1. Run "dmidecode > dmidecode.txt" as root. Actual results: dmidecode.txt is a 0-byte file. Expected results: dmidecode.txt should contain what normally goes to stdout when one runs "dmidecode".
In /var/log/messages, when running "dmidecode > dmidecode.txt", I get Aug 26 09:32:29 localhost kernel: audit(1156599149.690:8): avc: denied { write } for pid=7223 comm="dmidecode" name="dmidecode.txt" dev=dm-0 ino=11784984 scontext=user_u:system_r:dmidecode_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file Does this mean it's an SELinux bug instead? If so, please reassign. Thanks.
Interestingly, "biosdecode" doesn't have this problem, though "vpddecode" does. I don't know if "ownership" has it since it has no output on my machine anyway.
dmidecode should not be transitioned to by unconfined_t. THis will be fixed in the next released policy code. For the time being you can trick it by executing dmidecode | cat > dmidecode.txt
dmidecode, vpddecode, and ownership all generate the write denied message when redirecting to a file, so make sure the policy code fixes all three (and thanks for the workaround!).
Yes all files labeled dmidecode_exec_t will abide by the change. SELinux does not care about file names/paths, but file_context. So ls -lZ /usr/sbin/ownership shows it labeled dmidecode_exec_t so it will fallow this policy.
Fixed in selinux-policy-2.3.7-3.fc5
Don't think so. Just checked that this problem still exists in FC6, selinux-policy-2.3.18-10.
Check it against selinux-policy-2.4.1-3 which just went up for testing.
Appears fixed when using selinux-policy-2.4.1-3 and selinux-policy-targeted-2.4.1-3.