On 7/25/25 10:25, Zbigniew Jędrzejewski-Szmek wrote:
In the example, the print queue called `ricoh` uses the affected PPD options.
If its values are not allowed, the following situation will happen:
<pre>
$ lp -d ricoh /etc/fstab
$ journalctl -u cups -r
...
Job stopped due to filter errors; please consult the syslog file for details.
...
</pre>
If CUPS debug logs are enabled, there is a specific message in the journal:
This sounds like a gotcha — are debug logs enabled by default? If not,
the failure could be hard to figure out.
The expected flow here is to see the first error message, check the
journal, if there are no specific messages, I would guess the common
sense is to enable debug/verbose logging to find out more.
But we have a way how to relay errors from filters, so I've checked it
and found the issue (bad format message) -
https://github.com/OpenPrinting/cups-filters/pull/649 .
With this, the error message will be seen in the default configuration
as well.
<pre>
$ journalctl -u cups -r
...
Process is dying with \"ERROR: The value of the key
FoomaticRIPCommandLine is not among the allowed values - see
foomatic-rip man page for more instructions.
...
</pre>
User is expected to run `foomatic-hash`, to review the scan result in
`file_to_review`, and if the found values do not look malicious or the
user accepts them, to copy them into the directory
`/etc/foomatic/hashes.d`:
<pre>
$ sudo foomatic-hash --ppd-paths /etc/cups/ppd file_to_review local_hashes
$ sudo cp local_hashes /etc/foomatic/hashes.h
$ lp -d ricoh /etc/fstab
(Print job succeeds)
</pre>
Frankly, this doesn't sound like a process that we want users to go
through at all. Our goal is to make Fedora usable be non-expert users.
Non-expert users are expected to use printers which provide
functionality to work out of the box via mechanisms like IPP Everywhere
or AirPrint, which are present on SOHO devices for 10 years at least
(network devices since 2010, USB devices since approx 2015) - they don't
come into contact with foomatic-rip, thus they are not affected by the
change.
Foomatic-rip is usually used by devices older than 10 years, devices
with a specific usage (like some label printer which do not work
automatically on Mac yet) or users who opt-out from out of the box
functionality by their own will - IMO such users have or should have
some expertise if they opt-out from the mainstream.
How is the average user supposed to figure out if the complicated
command full of special characters is "safe"? Users are more likely
to give up or blindly accept the command.
This is no change from the current situation with classic, not-IPP
Everywhere drivers - currently they blindly accept a driver which
configuration tool assigns to the printer, or blindly download a driver
from a 3rd party.
The change gives the control over what is accepted by the filter and
users get awareness what they allowed, while most users are secured from
possible issues via foomatic-rip.
What about an alternative approach: sandbox the command. One option
would be use bubblewrap.
That would be a great approach if we had a complete control over Linux
drivers - some of foomatic-rip drivers have dead or unresponsive
upstreams, so any issues which are caused bwrap sandboxing would have to
fixed and maintained downstream, and a number of vendors do not provide
drivers under open source license at all - such problems would result
into a hope such device is still supported by driver vendor, and maybe
never fixed.
In general we are not able to say programmatically if what they do is
fine or not for not-insignificant number of foomatic-rip drivers -
because they are not open source, so we don't know what they do with the
input - and I fear using sandboxing would break valid use cases, which
will require allowing such values at the end after all.
Having a way to allow values at least gives you a way how to bypass such
issues after review.
Zdenek
The other option would be to use a transient
systemd service with a dynamic user, limited read-only access to the
file system and no ability to do privilege escalation, writing to files
outside of temporary directories, or network communication. Either way,
just severly limit what the command can do. This would have the additional
benefit that the sandbox would also cover "benign" pipelines, e.g. when
a crafted file that triggers undefined behaviour in the pipeline is
used.
Zbyszek
--
Zdenek Dohnal
Senior Software Engineer
Red Hat, BRQ-TPBC
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
