Bug 134144 - cupsd changes owner, group and permissions of SSL certificate
Summary: cupsd changes owner, group and permissions of SSL certificate
Status: RESOLVED INVALID
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Printing (show other bugs)
Version: Final
Hardware: Other SuSE Linux 10.0
: P5 - None : Major
Target Milestone: ---
Assignee: Klaus Singvogel
QA Contact: Johannes Meixner
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-17 10:48 UTC by Johannes Meixner
Modified: 2005-11-17 10:56 UTC (History)
1 user (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Meixner 2005-11-17 10:48:59 UTC
When cupsd starts, it changes owner, group and permissions
of a SSL certificate to "-rw-r-----  1 lp lp".

If it is a system wide used certificate, other services
can no longer use it.

How to reproduce:
Specify in /etc/cups/cupsd.conf a system wide certificate
(here it is the default system certificate on a SLES9):
----------------------------------------------------------
ServerCertificate /etc/ssl/servercerts/servercert.pem
ServerKey /etc/ssl/servercerts/serverkey.pem
----------------------------------------------------------

For your information:
By default the SLES9 system certificate is
(here on brie.hwlab.suse.de):
----------------------------------------------------------------
brie:~ # ls -ld /etc/ssl/servercerts/*
-rw-r--r--  1 root root ... /etc/ssl/servercerts/servercert.pem
-rw-r-----+ 1 root root ... /etc/ssl/servercerts/serverkey.pem

brie:~ # getfacl /etc/ssl/servercerts/serverkey.pem
getfacl: Removing leading '/' from absolute path names
# file: etc/ssl/servercerts/serverkey.pem
# owner: root
# group: root
user::rw-
user:ldap:r--
group::---
mask::r--
other::---
----------------------------------------------------------------
Comment 1 Klaus Singvogel 2005-11-17 10:56:49 UTC
yes, this is intended and required.