REJECTING access to capability 'dac_override' (cupsd(6348) profile /usr/sbin/cupsd active /usr/sbin/cupsd)

[Michael R. Head]

Binary package hint: cupsys

Unsure if this is a bad/OK thing, but I noticed this AppArmor generated line in syslog:
Aug 12 05:45:09 localhost kernel: [ 127.644000] audit(1186911909.517:9): REJECTING access to capability 'dac_override' (cupsd(6348) profile /usr/sbin/cupsd active /usr/sbin/cupsd)

I don't know what dac_override is, or why cupsd would need it, and things _seem_ OK, but maybe the capability needs to be added anyway.

[Bryan Quigley (bryanquigley)]

If it needs to be added. It would be added to apparmor

[Michael R. Head (burner)]

Huh? cupsys comes packaged with its apparmor profile. The /etc/apparmor.d/usr.sbin.cupsd file is what needs to be updated, not the apparmor program.

[Bryan Quigley (bryanquigley)]

My mistake. Do any other programs do it this way?

[Michael R. Head (burner)]

Dunno, AppArmor is new in main. I think the Ubuntu cupsys packager wanted to be on of the first to try and deploy an AppArmor profile for a service in main.

There are some apparmor profile packages in the Universe, but I don't know how well those work.

[Kees Cook (kees)]

Correct, the profile is in cupsys, not apparmor (I'm closing the apparmor task)

[Martin Pitt (pitti)]

Granting dac_override to cups would render the apparmor confinement largely irrelevant. It's an incredibly powerful capability, and cups should not have it. I did not see anything break because of it, so I won't change the profile for this. Did you?

Thank you for your report!

[Michael R. Head (burner)]

Ah. No, I haven't noticed any particular problems. Why does it attempt to get this permission?

[Bryan Quigley (bryanquigley)]

If it really should not have this capability, perhaps the fact that it does
is a bug in cupsys?

[Jesse Michael (jesse.michael)]

Granting the dac_override capability in an AA profile doesn't give away permission to access things not listed explicitly in the profile.

It gives root the ability to read and write files that it does not have group or other permission to access (e.g. user foo has a file named /home/foo/bar.txt with permission bits 0600), but the files still need to be listed in the profile in order for the program to be allowed access.

[Michael R. Head (burner)]

Ah... then I think I have seen some problems, because cups was unable to open some of its log files. Unfortunately, my laptop's hard drive died this week, and I had to reinstall on a brand new drive and I don't have the logs to post which show this. I'm hoping to get a USB to 2.5" PATA connector so I can copy some of my data off it.

[wlx (wangliangxu)]

I have the same problem.
and which log file you mean?
in /var/log/cups/ directory, both access_log and error_log file are zero file.

[Mathias Gug (mathiaz)]

The logs in /var/log/cups are group owned by the group lp (or lpadmin). However cups runs as root:root. This is why it needs the dac_override capability to be able to access the log files (beside being allowed to access the log files).

[Martin Pitt (pitti)]

I fixed the /var/log/cups/ permission issue in the latest development version now, will upload soon.