Re: Permission problem of PPDs in /etc/cups/ppd/ fixed
Hi,
I got an answer to
https://www.cups.org/str.php?L4703
and the upstream code got appropriately fixed, but the intended behavior
is not world-readable PPDs as it looked like but treating the PPDs in
/etc/cups/ppd/ as any other configuration file of CUPS, getting
permissions assigned as defined by the ConfigFilePerm variable in
/etc/cups/cups-files.conf. Ownerships are root.lp.
This means that world-readable PPD files are not standard in CUPS and
any access to printer capabilities and any other information cocerning
the printing environment have to be done via IPP requests to the CUPS
daemon or via API functions of the CUPS library (which in turn send IPP
requests to the CUPS daemon). Also locations of CUPS files are not
necessarily always the same, as we got used to with standard desktop or
server Linux. So the files should never get accessed directly. If a
program fails on not world-readable PPDs, it has a bug.
Now we need to decide about the further proceeding:
1. Leave ConfigFilePerm on its default of 640, meaning that all config
files including the PPDs are not world-readable. Is there any security
reason why config files of CUPS should not be world-readable?
2. Set ConfigFilePerm to 644, making all config files and PPD
world-readable to work around bugs in programs which want to access PPDs
and/or config files of CUPS directly
3. Create a distro patch which allows world-readable PPDs but
not-world-readable config files in CUPS.
I would say to go with (2) if this does not bear any security risk,
otherwise with (1). I think (3) would be too awkward.
Only program I know about that it has problems with not world-readable
PPDs is the Chromium browser. Its native print dialog hangs if a printer
with not world-readable PPD is selected. Only way out is to select
another printer or to click the link for using the system's print dialog
(standard GTK dialog, always works).
Till
On 08/28/2015 09:03 AM, Till Kamppeter wrote:
Hi,
a long-standing problem of CUPS is that depending on how a print queue
is created or modified the CUPS daemon writes the PPD with different
permissions/ownerships, sometimes world-readable and sometimes not. Some
programs, like the print dialog of Chromium cannot cope with
non-world-readable PPDs.
I have described what happens and fixed it in
https://www.cups.org/str.php?L4703
and I have also committed this patch to the experimental branch (the one
with CUPS 2.1rc1) of the Debian GIT.
This is the actual fix of this Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784271
The bug got marked fixed in error as a change in CUPS came up which made
CUPS itself coping with the varying permissions but the varying
permissions still were there. So my patch is the real fix, but with the
bug already archived I do not know what to do here. Perhaps someone of
you can help.
By the way, can someone of you do a release of the experimental branch
with my fix (2.1~rc1-4) so that I can sync it into Ubuntu Wily? Thanks.
Till
Reply to: