Re: Permission problem of PPDs in /etc/cups/ppd/ fixed
On 09/03/2015 04:56 PM, Didier 'OdyX' Raboud wrote:
Hi Till,
This is my "other mail". Sorry for the delay.
Le vendredi, 28 août 2015, 12.15:39 Till Kamppeter a écrit :
I got an answer to STR #4703 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.
If that's to stay, we should probably make sure all files under
/etc/cups/ppd/ have these ownerships in a postinst script.
OK, no problem. The postinst script should read out what cownerships and
permissions CUPS is about to use and change the ownerships and
permissions of all already existing CUPS config files appropriately.
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.
Fair enough, and I think we should follow upstream there, although it's
always puzzling to have non-standard configuration files under /etc.
What do you mean with non-standard config files? non-standard
permissions and ownerships? Or something else?
To recap, I think upstream's opinion on what the various file
permissions and ownerships should be are consistent with how CUPS works,
but it's inconsistent with FHS. We could consider moving some sub-
directories to /var/lib/cups, where FHS wants them.
What does FHS require? World-readable? root.root ownerships? Look for
example here:
$ ll /etc/shadow
-rw-r----- 1 root shadow 1346 Apr 30 07:06 /etc/shadow
$
Do files have to go to /var if they do not fulfill FHS ownerships and
permissions?
They are still config files. A PPD describes the configuration of its
corresponding print queue. And they do not change with printer status or
job execution.
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?
For now, that's what 2.0.1-1 will do. :) But in this case, these files
should move to /lib.
CUPS config files non-world-readable are no problem for me, only
offending app is the Chromium browser, I have already reported a bug to
Ubuntu about it:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1490055
So the real problem of the non-world-readable config files is that it
breaks FHS rules? Do these rules have a special reason?
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
If these files are to stay in /etc, that's probably what we should be
doing. But in terms of security, I think some configuration files can
hold samba credentials, and should therefore not be world-readable.
Yes, there are Samba credentials, but only in the
/etc/cups/printers.conf file. A good solution would be if CUPS allows
different permissions for different files, only closing the ones which
can contain credentials or other confidential info. Even better would be
to completely seperate the confidential info from general configuration,
as one does with /etc/passwd and /etc/shadow.
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.
Yeah, agreed.
Seems that we have to go with (1) due to these Samba credentials.
And it also seems that there can be always confidential config bits, so
that an FHS rule requiring world-readable config files should be done
away with.
Till
Reply to: