I tried printing a few pages from Acrobat Reader in SELinux enforcing mode and it did not work. The messages were: audit(1081195244.523:0): avc: denied { write } for pid=8657 exe=/usr/bin/lpr.cups path=/tmp/Acro7QtkQf dev=hda2 ino=212837 scontext=aleksey:staff_r:staff_lpr_t tcontext=aleksey:object_r:staff_tmp_t tclass=file audit(1081195244.523:0): avc: denied { write } for pid=8657 exe=/usr/bin/lpr.cups path=/tmp/AcroJTppcX dev=hda2 ino=212838 scontext=aleksey:staff_r:staff_lpr_t tcontext=aleksey:object_r:staff_tmp_t tclass=file audit(1081195244.523:0): avc: denied { write } for pid=8657 exe=/usr/bin/lpr.cups path=/tmp/AcroHpllmJ dev=hda2 ino=344750 scontext=aleksey:staff_r:staff_lpr_t tcontext=aleksey:object_r:staff_tmp_t tclass=file audit(1081195244.523:0): avc: denied { write } for pid=8657 exe=/usr/bin/lpr.cups path=/tmp/AcrovwMsZC dev=hda2 ino=344801 scontext=aleksey:staff_r:staff_lpr_t tcontext=aleksey:object_r:staff_tmp_t tclass=file audit(1081195244.523:0): avc: denied { write } for pid=8657 exe=/usr/bin/lpr.cups path=/tmp/Acro4mBKoE dev=hda2 ino=344924 scontext=aleksey:staff_r:staff_lpr_t tcontext=aleksey:object_r:staff_tmp_t tclass=file audit(1081195244.523:0): avc: denied { write } for pid=8657 exe=/usr/bin/lpr.cups path=/tmp/AcroWBqMdI dev=hda2 ino=344937 scontext=aleksey:staff_r:staff_lpr_t tcontext=aleksey:object_r:staff_tmp_t tclass=file audit(1081195244.523:0): avc: denied { write } for pid=8657 exe=/usr/bin/lpr.cups path=/tmp/AcromVNo5A dev=hda2 ino=344979 scontext=aleksey:staff_r:staff_lpr_t tcontext=aleksey:object_r:staff_tmp_t tclass=file audit(1081195249.465:0): avc: denied { ioctl } for pid=8659 exe=/usr/bin/perl path=/etc/foomatic/filter.conf dev=hda2 ino=229011 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:etc_t tclass=file audit(1081195249.821:0): avc: denied { ioctl } for pid=8664 exe=/usr/bin/perl path=/etc/foomatic/filter.conf dev=hda2 ino=229011 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:etc_t tclass=file audit(1081195253.151:0): avc: denied { read } for pid=8665 exe=/usr/bin/gs name=Identity-H dev=hda2 ino=3859274 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t tclass=lnk_file
After I've added the following to my local policy adds file: allow staff_lpr_t staff_tmp_t:file { write }; allow cupsd_t usr_t:lnk_file { read }; it started working again. Adding just the first line out of the two was insufficient. I currently have policy-sources-1.9.2-10
I added the cups rule, but I don't like the allow staff_lpr_t staff_tmp_t:file { write }; Does the policy you have contain tmp_domain($1_lpr) in macros/program/lpr_macros.te? Dan
Yes, and in the policy.conf file it ends up expending to: type staff_lpr_tmp_t, file_type, sysadmfile, tmpfile ; allow staff_lpr_t tmp_t:dir { read getattr lock search ioctl add_name remove_name write }; allow staff_lpr_t staff_lpr_tmp_t:{ file lnk_file sock_file fifo_file } { create ioctl read getattr lock write setattr append link unlink rename }; allow staff_lpr_t staff_lpr_tmp_t:dir { create read getattr lock setattr ioctl link unlink rename search add_name remove_name reparent write rmdir }; type_transition staff_lpr_t tmp_t:dir staff_lpr_tmp_t; type_transition staff_lpr_t tmp_t:{ file lnk_file sock_file fifo_file } staff_lpr_tmp_t; allow staff_lpr_t staff_tmp_t:dir { read getattr lock search ioctl }; allow staff_lpr_t staff_tmp_t:{ file lnk_file } { read getattr lock ioctl }; allow staff_lpr_t staff_tmp_t:file { write };
Sorry, ignore the last line (it was from my local add). The lines are type staff_lpr_tmp_t, file_type, sysadmfile, tmpfile ; allow staff_lpr_t tmp_t:dir { read getattr lock search ioctl add_name remove_name write }; allow staff_lpr_t staff_lpr_tmp_t:{ file lnk_file sock_file fifo_file } { create ioctl read getattr lock write setattr append link unlink rename }; allow staff_lpr_t staff_lpr_tmp_t:dir { create read getattr lock setattr ioctl link unlink rename search add_name remove_name reparent write rmdir }; type_transition staff_lpr_t tmp_t:dir staff_lpr_tmp_t; type_transition staff_lpr_t tmp_t:{ file lnk_file sock_file fifo_file } staff_lpr_tmp_t; allow staff_lpr_t staff_tmp_t:dir { read getattr lock search ioctl }; allow staff_lpr_t staff_tmp_t:{ file lnk_file } { read getattr lock ioctl };
And with this policy you are still getting the errors without the allow staff_lpr_t staff_tmp_t:file { write }; line? Dan
Aleksey, is this still a problem with current (say, 1.11.2-9) policy?
Have not tried actually printing (I am away from my printer ATM), but I do see audit(1082388723.427:0): avc: denied { write } for pid=4579 exe=/usr/bin/lpr.cups path=/tmp/Acro5hiEsy dev=hda2 ino=212850 scontext=aleksey:staff_r:staff_lpr_t tcontext=aleksey:object_r:staff_tmp_t tclass=file
I don't really understand how that can happen. You said you have this in policy.conf: allow staff_lpr_t staff_lpr_tmp_t:{ file lnk_file sock_file fifo_file } { create ioctl read getattr lock write setattr append link unlink rename }; so adding 'allow staff_lpr_t staff_lpr_tmp_t:file {write};' should have no effect, and AFAICT you shouldn't be getting audit messages for that situation. Which version of policy do you have at the moment?
Note that it complains about staff_tmp_t, not staff_lpr_tmp_t! OTOH I have no idea why it wants to write to it and it does print fine.
Oh I see! So acroread is writing a temporary file (and it becomes staff_tmp_t), and running 'lpr -r /tmp/...'. That's my guess -- you could verify it with 'strace -feexecve acroread ...'. The -r option tells lpr to remove the file after it's printed it. Can you try printing from acroread in permissive mode please (setenforce 0), so that we can see all of the messages? I expect to see a denial for 'unlink' too. Daniel: do we want to allow 'lpr' to remove files, or leave '-r' broken? (What a choice..)
lpr -r shouldn't generate a write denial, just an unlink denial. Quick experiment of 'touch /tmp/myfoo; lpr -r /tmp/myfoo' confirms this behavior on my system. So I'm still not clear as to why it needs write permission at all.
Ok I got the bug, but I have no idea what is going on. When I strace it I don't get the bug. I will attach the strace next Sep 30 15:54:26 dhcppc1 kernel: audit(1096574066.107:0): avc: denied { write } for pid=15837 exe=/usr/bin/lpr.cups path=/tmp/AcroAvv1Xo dev=dm-0 ino=3070617 scontext=user_u:user_r:user_lpr_t tcontext=user_u:object_r:user_tmp_t tclass=file
Created attachment 104600 [details] strace of acroread This is the strace, looks like it is doing a standard lpr command.
Using acroread-5.0.9 and selinux-policy-strict-1.19.1-10 I don't see this problem any longer. Dan
Reporters, does FC4 or devel work for you too?