Bug 1195288 - CUPS complains about "Read-only file system" although it is writable
CUPS complains about "Read-only file system" although it is writable
: 1193134 1193216 1195289 (view as bug list)
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Printing
All openSUSE Tumbleweed
: P3 - Medium : Major (vote)
: ---
Assigned To: Johannes Meixner
Johannes Meixner
Depends on:
Blocks: 1181400
  Show dependency treegraph
Reported: 2022-01-28 17:48 UTC by Axel Schwarzer
Modified: 2022-06-03 12:55 UTC (History)
4 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Axel Schwarzer 2022-01-28 17:48:32 UTC
In /usr/lib/systemd/system/cups.service is sandboxing enabled due to https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort .

The line "ProtectSystem=full" mounts /etc read-only for the service but here we have CUPS_SERVERROOT=/etc/cups and cupsd needs to write exactly here. Setting "ProtectSystem=true" is sufficient and restores the functionality of service cups.
Comment 1 Axel Schwarzer 2022-01-28 18:05:57 UTC
cups-browsed.service seems to have the same issue.
Comment 3 Johannes Meixner 2022-01-31 07:37:41 UTC
Johannes Segitz,
could you please have a look here.

I have only very basic systemd knowledge
so I cannot imagine what the initial changes
and the proposed changes here in comment#0
mean in practice.
Comment 4 Johannes Meixner 2022-01-31 07:58:13 UTC
*** Bug 1193216 has been marked as a duplicate of this bug. ***
Comment 5 Johannes Meixner 2022-01-31 08:00:58 UTC
*** Bug 1195289 has been marked as a duplicate of this bug. ***
Comment 6 Johannes Meixner 2022-01-31 08:02:34 UTC
"adding ReadWritePaths=/etc/cups to both units"
Comment 7 Johannes Segitz 2022-02-01 07:59:07 UTC
Sorry for the breakage. Didn't expect cups to write to /etc

The solution outlined in https://bugzilla.suse.com/show_bug.cgi?id=1195289#c1 is the correct one. Would you like me to submit or will you add it yourself?
Comment 8 Johannes Meixner 2022-02-01 08:59:54 UTC
Johannes Segitz,
thank you for the info!
This is what I need - i.e. what "the right setting" is for systemd.
I will fix CUPS and cups-filters myself.

FYI what cupsd basically does:

All print queue setup things happen via the cupsd.
A a client (e.g. the local lpadmin command) only
talks to the cupsd and the cupsd does the actual setup, cf.
"How to set up a print queue in full compliance with CUPS" in
For printer autodetection a client calls "lpinfo" which
talks to the cupsd and the cupsd runs each so called backend, cf.
in /usr/lib/cups/backend as child processes to let each
backend autodetect its printers.
Some backends run as root to be able to access device nodes
to access the actual printer devices.
Some backends are wrappers that call other backends.
CUPS backends are arbitrary programs that implement
whatever is needed to send printing data to a printer
and alternativerly to autodetect printer devices.

All print job processing is done via the cupsd.
A local or remote client submits a print job to the cupsd.
The cupsd stores print job data in /var/spool/cups.
To get a print job output on a printer device
the cupsd runs several so called filters as child processes.
Those filters are arbitrary programs (normally run as 'lp')
that implement whatever is needed to produce printing data
for a specific printer from the original print job data.
Often filters call other programs as child processes
(e.g. several filters call Ghostscript).

If those systemd sandboxing restrictions do not only apply
to the cupsd itself but when also child processes inherit them
then it becomes likely highly problematic to keep the current
functionality what current CUPS backends and filters
need to do to make printing work in all currently
implemented cases (which are more than I can remember).
Comment 9 Johannes Meixner 2022-02-01 10:16:11 UTC
Added ReadWritePaths=/etc/cups to cups.service
for cups in OBS Printing and forwarded it to openSUSE:Factory
# osc request accept -m \
 'Added ReadWritePaths=/etc/cups to cups.service (boo#1195288)' \

Result of change request state: ok
Forward this submit to it? ([y]/n)y
Added ReadWritePaths=/etc/cups to cups.service (boo#1195288)
 (forwarded request 950380 from jsmeix)
New request # 950381

I added print queues via command line ('lpadmin'),
via the YaST printer module and
via the CUPS web interface ('localhost:631')
which worked for me
and I printed as normal user to those three queues
via command line ('echo Hello | lp -d <queue_name>')
which also worked for me.

I cannot test printing via network on my homeoffice laptop.
Comment 10 Johannes Meixner 2022-02-01 10:31:53 UTC
As an example of a special use case:
I guess "ProtectHome=true" conflicts with what
cups-pdf could do if configured (not by default),
cf. "PDF output location" in
when cupsd also child processes inherit cupsd restrictions
(here the cups-pdf backend).
Comment 11 OBSbugzilla Bot 2022-02-01 10:40:04 UTC
This is an autogenerated message for OBS integration:
This bug (1195288) was mentioned in
https://build.opensuse.org/request/show/950381 Factory / cups
Comment 12 Johannes Meixner 2022-02-01 10:53:37 UTC
Now I understand why there are not tons of such bug reports:

shows that the initial hardening of cupsd.service
via harden_cups.service.patch had somehow never made it
into openSUSE:Factory - as far as I understand it.

So the Product "openSUSE Tumbleweed" seems plain wrong
in this bug report here and actually it happened only
to those users who use CUPS from the OBS Printing
development project - so bug #1195289 is the actually
right description with the actually right fix.

See also

Now let's wait and see how hell breaks loose when that
hardening of cupsd.service appears in Tumbleweed ;-)
Comment 13 Johannes Meixner 2022-02-01 10:57:35 UTC
Because cups-filters in Tumbleweed has already the hardening
of cups-browsed.service since about Oct 2021
and I got no bugs about cups-browsed because of this
I leave the hardening of cups-browsed.service as is.
Comment 14 Dominique Leuenberger 2022-02-01 13:26:55 UTC
(In reply to Johannes Meixner from comment #13)
> Because cups-filters in Tumbleweed has already the hardening
> of cups-browsed.service since about Oct 2021
> and I got no bugs about cups-browsed because of this
> I leave the hardening of cups-browsed.service as is.


That had been reverted twice in Factory already

r161 | dimstar_suse | 2022-01-02 10:54:36 | c26f8459d144d35ccbc99b238233d4c7 | 2.3.3op2 | 

r160 | dimstar_suse | 2021-12-31 12:44:18 | b22f316054d9ca9c71f6e799862995c4 | 2.3.3op2 | rq943130

Automatic submission by obs-autosubmit
r159 | dimstar_suse | 2021-11-27 23:37:25 | afdb86c476ff86443f30923f09d1f266 | 2.3.3op2 | 

r158 | dimstar_suse | 2021-11-26 23:50:44 | b22f316054d9ca9c71f6e799862995c4 | 2.3.3op2 | rq933432

Automatic submission by obs-autosubmit
Comment 15 Johannes Meixner 2022-02-01 13:47:19 UTC
Dominique Leuenberger

are both about CUPS.

CUPS and cups-filters are totally separated source Packages
from different upstream projects.

As far as I can imaginge what
shows that has nothing to do with cups-browsed.
Comment 16 Georg Jansing 2022-02-03 07:14:00 UTC
Fix just landed my updates, removed my workaround and printing still works (tested with CUPS-PDF via VPN). :)
So fixed for me. Since this bug is not mine, I don't close it.
Thanks everyone!
Comment 17 Johannes Meixner 2022-06-03 12:51:47 UTC
This one is fixed since (excerpt from cups.changes):
Tue Feb  1 09:18:27 UTC 2022 - jsmeix@suse.de

- Enhanced harden_cups.service.patch by adding
  because cupsd needs write access in /etc/cups
Comment 18 Johannes Meixner 2022-06-03 12:55:05 UTC
*** Bug 1193134 has been marked as a duplicate of this bug. ***