Inconsistent ownership/permissions of error_log in CUPS

OdyX, pitti, I have never modified the ownership policy of CUPS' log files. So I do not know which is the intended one root:adm? root:lpadmin? 640? 644? What is the intended policy and what is its rationale?

Log files which can potentially contain sensitive data should usually be <system_user>:adm 640; the group "adm" purpose is that members can read system log files. For "harmless" log files they can be root:root (or from a system user if the daemon is not running as root) and 644.

It would be good if cups could stick to that as well, i. e. either use root:adm 640 or 644; as print jobs and information about them might potentially be sensitive, the former seems better?

This all is not new. From the git history, LP: #345953 got fixed by the inclusion of the current (and mostly unchanged) of the logfiles_adm_readable.dpatch by Martin for 1.3.9-16. The logrotate script exists at least since cups 1.2. It has enforced "640 root lp" since 1.3.8-1.

That said, I open to fixing this. I agree with mode 0640 but my only doubt is whether the group 'adm' is okay, rather than lpadmin. Users are not necessarily in both groups; therefore "adm" is the generic solution but could potentially forbid "lpadmin" users logfiles access (which, at a second thought, is probably fine).

Therefore:
* cups should be creating the logfiles 640 root:adm
* logrotate should only let them be recreated that way too.

Opinions about the attached patch?

Cheers, OdyX

The attachment "0001-Consolidate-logfiles-modes-and-groups-to-be-0640-and.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

OdyX, thanks for the patch, it looks OK for me. Please go ahead and apply it to the next Debian package. Ubuntu will pick it up by auto-syncing then.

Maybe you could avoid creating an empty file at all, or enforcing any permissions on it? (logrotate would copy previous permissions by default). From admin's point of view, it is cumbersome to adjust log files permissions in two places: cups-files.conf and logrotate for CUPS.

Thanks Didier, looks fine!

I noticed a problem in my patch: it is useless. :-) From the reporter: "At the same time, CUPS itself sets its log files by default to 644." This is wrong; debian/rules sets LogFilePerm to 0640 through the "--with-log-file-perm=0640" configure argument. It has been this way since cups 1.3.8-6 to fix Debian's #469853 .

I will therefore just apply a different logrotate change to only specify "create" instead of specifying the mode, group and user.

This bug was fixed in the package cups - 1.7.1-3

---------------
cups (1.7.1-3) unstable; urgency=low

  [ Till Kamppeter ]
  * Split binary package "cups" into "cups" and "cups-core-drivers". In
    low-footprint (mobile) environments we can restrict the printer
    support to only IPP printers with known common languages (PDF,
    PostScript, PWG Raster, PCL) to get rid of the heavy load of drivers
    and PPDs for thousands of printers. From CUPS we need only the
    "cups-daemon" and "cups-core-drivers" (plus library packages) then.
    "cups-core-drivers" currently only contains the gziptoany and pstops
    filters.

  [ Didier Raboud ]
  * Avoid specifying mode, user and (wrong) group in the logrotate
    'create' statement (LP: #1268011)
  * Install cups-daemon AppArmor, ufw profile and apport hooks on Debian
    too (Closes: #735313)
  * Replace custom AppArmor post{inst,rm} machinery with a dh_apparmor
    call
  * Add patch to move cupsd.conf.default from /etc/cups to
    /usr/share/cups as it's not a configuration file (Closes: #640124)
  * Reorder most patches to let those that upstream doesn't intend to
    fix stay on top of the pile; most also mark those reported upstream
    as such
  * Drop configure-default-browse-protocols patch, now useless
  * Drop update-rc.d arguments in Debian, as they are no longer
    supported

  [ Helge Kreutzmann ]
  * Update German man page (1518t)

 -- Didier Raboud <email address hidden> Mon, 20 Jan 2014 23:06:36 +0100