Bug 120071

Summary: Printing from Acroread does not work.
Product: [Fedora] Fedora Reporter: Aleksey Nogin <aleksey>
Component: cupsAssignee: Daniel Walsh <dwalsh>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: djuran, dwalsh, marius.andreiana, rcoker, sdsmall, twaugh, wtogami
Target Milestone: ---Keywords: SELinux
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: FC5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-06-16 02:45:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 122683    
Attachments:
Description Flags
strace of acroread none

Description Aleksey Nogin 2004-04-05 20:01:41 UTC
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

Comment 1 Aleksey Nogin 2004-04-05 20:12:24 UTC
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

Comment 2 Daniel Walsh 2004-04-05 20:44:50 UTC
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

Comment 3 Aleksey Nogin 2004-04-06 04:34:28 UTC
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 };


Comment 4 Aleksey Nogin 2004-04-06 04:35:18 UTC
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 };

Comment 5 Daniel Walsh 2004-04-06 10:24:02 UTC
And with this policy you are still getting the errors without the
allow staff_lpr_t staff_tmp_t:file { write };


line?

Dan

Comment 6 Tim Waugh 2004-04-19 12:57:37 UTC
Aleksey, is this still a problem with current (say, 1.11.2-9) policy?

Comment 7 Aleksey Nogin 2004-04-19 15:28:09 UTC
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


Comment 8 Tim Waugh 2004-04-20 17:45:09 UTC
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?

Comment 9 Aleksey Nogin 2004-04-20 18:44:18 UTC
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.

Comment 10 Tim Waugh 2004-04-21 09:41:04 UTC
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..)

Comment 11 Stephen Smalley 2004-07-28 18:31:35 UTC
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.


Comment 12 Daniel Walsh 2004-09-30 19:54:34 UTC
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


Comment 13 Daniel Walsh 2004-09-30 19:56:42 UTC
Created attachment 104600 [details]
strace of acroread

This is the strace, looks like it is doing a standard lpr command.

Comment 15 Daniel Walsh 2004-11-17 22:20:07 UTC
Using acroread-5.0.9
and selinux-policy-strict-1.19.1-10
I don't see this problem any longer.

Dan

Comment 16 Marius Andreiana 2005-08-19 20:36:34 UTC
Reporters, does FC4 or devel work for you too?