Mislabeled files

# restorecon -R -v /etc/cups

Will fix.

Any idea how these files got created?

I saw this on my F10 system after it was upgraded from F9.

type=ANOM_ABEND msg=audit(11/20/08 14:47:38.430:12) : auid=unset uid=root gid=root ses=4294967295 subj=root:system_r:rpm_t:s0 pid=15372 comm=rpmq sig=Floating point exception

(In reply to comment #1)
> Mislabeled files
> 
> # restorecon -R -v /etc/cups
> 
> Will fix.
> 
> Any idea how these files got created?

Well, they're owned by cups, but system-config-printers writes to some of them, and that is what I used to configure the printers. In case it is helpful:

# ls -lRZ /etc/cups
/etc/cups:
-rw-------  root lp system_u:object_r:cupsd_rw_etc_t:s0 classes.conf
-rw-------  root lp system_u:object_r:cupsd_rw_etc_t:s0 classes.conf.O
-rw-r--r--  root lp system_u:object_r:etc_t:s0       client.conf
-rw-r-----  root lp system_u:object_r:cupsd_rw_etc_t:s0 cupsd.conf
-rw-r-----  root lp system_u:object_r:cupsd_rw_etc_t:s0 cupsd.conf.default
drwxr-xr-x  root root system_u:object_r:cupsd_etc_t:s0 interfaces
-rw-r--r--  root lp system_u:object_r:cupsd_rw_etc_t:s0 lpoptions
-rw-r--r--  root root system_u:object_r:cupsd_etc_t:s0 mime.convs
-rw-r--r--  root root system_u:object_r:cupsd_etc_t:s0 mime.types
-rw-r--r--  root lp system_u:object_r:cupsd_etc_t:s0 pdftops.conf
drwxr-xr-x  root lp system_u:object_r:cupsd_etc_t:s0 ppd
-rw-------  root lp unconfined_u:object_r:cupsd_rw_etc_t:s0 printers.conf
-rw-------  root lp system_u:object_r:cupsd_rw_etc_t:s0 printers.conf.O
-rw-r--r--  root root system_u:object_r:cupsd_etc_t:s0 pstoraster.convs
-rw-r--r--  root lp system_u:object_r:cupsd_etc_t:s0 snmp.conf
drwx------  root lp system_u:object_r:cupsd_etc_t:s0 ssl
-rw-r-----  root lp unconfined_u:object_r:cupsd_etc_t:s0 subscriptions.conf
-rw-r-----  root lp unconfined_u:object_r:cupsd_etc_t:s0 subscriptions.conf.O

/etc/cups/interfaces:

/etc/cups/ppd:
-rw-r--r--  root root system_u:object_r:cupsd_rw_etc_t:s0 HP4300.ppd

/etc/cups/ssl:

(In reply to comment #4)
> Well, they're owned by cups, but system-config-printers writes to some of them,
> and that is what I used to configure the printers.

Actually system-config-printer tells cupsd to alter them, it doesn't write to them directly.

The interesting thing is that /etc/cups/subscriptions.conf has 'unconfined_u' there, and so does printers.conf.  Were these files hand-edited (say, with vi or whatever) at any point?

Or alternatively, was cupsd ever restarted from an "unusual" security context (e.g. 'sudo su -' in a VNC session)?

(In reply to comment #5)
> The interesting thing is that /etc/cups/subscriptions.conf has 'unconfined_u'
> there, and so does printers.conf.  Were these files hand-edited (say, with vi
> or whatever) at any point?
> 

I can definitely say I have never hand edited any of those files.

> Or alternatively, was cupsd ever restarted from an "unusual" security context
> (e.g. 'sudo su -' in a VNC session)?

Nope, cups has only ever been started at boot on this particular machine.

HTH.

unconfined_u:object_r:cupsd_etc_t:s0 subscriptions.conf.O

This means some app launched by an unconfined_u user modified the file.  I would suspect system-config-* or a package install via yum or rpm.

system-config-printer does not touch files in /etc/cups itself, so yum/rpm sounds like the culprit.  Currently trying to reproduce the problem with a F9->F10 upgrade.

Not sure if this is a clue:

rpm -q --whatprovides /etc/cups/*
cups-1.3.9-1.fc9.x86_64
file /etc/cups/classes.conf.O is not owned by any package
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
file /etc/cups/printers.conf.O is not owned by any package
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
file /etc/cups/subscriptions.conf.O is not owned by any package


Perhaps whatever is moving the *.conf to *.conf.0 is the culprit. I don't know what is doing that though.

(In reply to comment #5)
> Or alternatively, was cupsd ever restarted from an "unusual" security context
> (e.g. 'sudo su -' in a VNC session)?

Hm, maybe I misunderstood this question, so to be clear: On the machine in question I do frequently use a VNC client (vinagre) to connect to remote (F-9) machines. On the machine in question I have not run a VNC server, ever. (I think the latter point is what you were asking, but I wasn't 100 percent sure.)

There is a chance cups could be running as unconfined_u, my earlier statement is false.

# service cups restart
Stopping cups:                                             [  OK  ]
Starting cups:                                             [  OK  ]
You have new mail in /var/spool/mail/root
# ps -eZ | grep cups
unconfined_u:system_r:cupsd_t:SystemLow-SystemHigh 3103 ? 00:00:00 cupsd
unconfined_u:system_r:cupsd_t:SystemLow-SystemHigh 3104 ? 00:00:00 cups-polld
unconfined_u:system_r:cupsd_t:SystemLow-SystemHigh 3105 ? 00:00:00 cups-polld


Now if a process running as cupsd_t, cupsd_config_t, or cupsd_lpd_t created the file it would be labeled cups_rw_etc_t as it should.  All other confined domains would not be allowed to create the file if running in enforcing mode.  An unconfined domain (unconfined_t, rpm_t, initrc_t) could create the file and it would be labeled cups_etc_t.  THe setroubleshoot indicates the machine was run in enforcing mode.  Did you run the machine in permissive mode?

(In reply to comment #9)
> Perhaps whatever is moving the *.conf to *.conf.0 is the culprit. I don't know
> what is doing that though.

That's cupsd, but it just renames conf -> conf.O when writing a new conf file.  Newly created files will have the correct context when created by cupsd due to policy.

(In reply to comment #10)
> Hm, maybe I misunderstood this question, so to be clear: On the machine in
> question I do frequently use a VNC client (vinagre) to connect to remote (F-9)
> machines. On the machine in question I have not run a VNC server, ever. (I
> think the latter point is what you were asking, but I wasn't 100 percent sure.)

Yes, my question was about running a VNC server, as that runs in an "unusual" security context (unconfined_u:system_r:unconfined_notrans_t:s0).

(In reply to comment #11)
> There is a chance cups could be running as unconfined_u, my earlier statement
> is false.

Ah, OK.  It still seems to be a mystery how those files are getting cupsd_etc_t instead of cupsd_rw_etc_t though.  My F9->F10 upgrade has finished, and I don't see the problem here.  /etc/cups/*.conf all have the correct file context.

Warren: how did you perform the upgrade?  Booting an ISO?

(In reply to comment #12)
> (In reply to comment #9)
> > Perhaps whatever is moving the *.conf to *.conf.0 is the culprit. I don't know
> > what is doing that though.
> 
> That's cupsd, but it just renames conf -> conf.O when writing a new conf file. 
> Newly created files will have the correct context when created by cupsd due to
> policy.

Oh, right, OK. [As an aside, the cups package should probably own the .0 files so they're cleaned up on removal of cups?].

(In reply to comment #11)
[snip]
> run in enforcing mode.  Did you run the machine in permissive mode?

AFAIK I have left the machine in enforcing mode since day 1 of the F-9 install.

If you ran a vncserver and restarted cups you could get this problem.

login via vnc, su to root, service restart cups, do something to  cause the subscripttions file to get recreated.

(In reply to comment #17)
> If you ran a vncserver and restarted cups you could get this problem.
> 
> login via vnc, su to root, service restart cups, do something to  cause the
> subscripttions file to get recreated.

Yup, definitely never did that. :)

Well if it comes back reopen the bug.