Agree regarding read-only /usr setups. Looks like
cups is writing a python file called
/usr/share/printconf/util/backend.pyo.
Here are avc's from a permissive boot
(sorry I forgot to include in original message):
Aug 2 07:33:27 fedora kernel: audit(1091457207.688:0): avc: denied {
write }
for pid=1997 exe=/usr/bin/python name=util dev=hda2 ino=4309019
scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t
tclass=dir
Aug 2 07:33:27 fedora kernel: audit(1091457207.689:0): avc: denied {
remove_name } for pid=1997 exe=/usr/bin/python name=backend.pyo
dev=hda2 ino=4309038 scontext=system_u:system_r:cupsd_t
tcontext=system_u:object_r:usr_t tclass=dir
Aug 2 07:33:27 fedora kernel: audit(1091457207.726:0): avc: denied {
add_name } for pid=1997 exe=/usr/bin/python name=backend.pyo
scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t
tclass=dir
Aug 2 07:33:27 fedora kernel: audit(1091457207.726:0): avc: denied {
create } for pid=1997 exe=/usr/bin/python name=backend.pyo
scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t
tclass=file
Aug 2 07:33:27 fedora kernel: audit(1091457207.728:0): avc: denied {
write }
for pid=1997 exe=/usr/bin/python
path=/usr/share/printconf/util/backend.pyo dev=hda2 ino=4309038
scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t
tclass=file
Sigh....
[/usr/share/printconf/util/ contains a bunch of python .py
and .pyo files, a file named 'smbprint', and a file named
'strip_control_file.sh'. All the files are labeled
system_u:object_r:printconf_t, except for one named
'print.py'. It is labeled system_u:object_r:bin_t.]
I'll file a bugzilla against cups for this....
tom
Russell Coker wrote:
On Mon, 2 Aug 2004 07:00, Tom London <selinux(a)comcast.net>
wrote:
>I noticed what I think are new avcs coming from starting cups:
>
>Aug 1 13:49:59 fedora kernel: audit(1091393399.153:0): avc: denied {
>write }
>for pid=2117 exe=/usr/bin/python name=util dev=hda2 ino=4309019
>scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t
>tclass=dir
>
>ino#4309019 is /usr/share/printconf/util
>(not sure why cups wants to write there ....)
>
>
What is under that directory tree?
What does cups do in this situation if you put the machine in permissive mode
and do the same print operation?
Naturally we can't give cups access to usr_t. We could use a different label
for the directory in question as an interim measure. But I think that this
is really a bug in cups. I don't think that there's any good reason for cups
to be writing there. I think that systems with a /usr file system mounted
read-only should work fine as print servers!