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@xxxxxxxxxxx> 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!
