Allow overriding lp and lpr binary paths in PSPrintJob

Rolf van Kleef rolf at vankleef.me
Wed Oct 27 08:43:16 UTC 2021


Hi Thomas,

October 27, 2021 9:31 AM, "Thomas Stüfe" <thomas.stuefe at gmail.com> wrote:

> Hi Rolf,
> 
> On Tue, Oct 26, 2021 at 9:30 PM Rolf van Kleef <rolf at vankleef.me> wrote:
> 
>>> Well ..
>>> 
>>> 1) Please read the comment the bots added to your PR.
>>> There are steps you need to take before we can even look at your contribution.
>>> 
>>> 2) PRs need a JBS bug ID else the bots will still reject it.
>>> You'll need to submit an RFE at bugreport.java.com and go from there.
>> 
>> I have submitted a bug, and added a bug ID to the PR. The only remaining requirement appears to e
>> acquiring a review.
>> 
>>> 3) I understand your problem up to a point but we'd need to think about the proposed solution
>>> and why your Linux doesn't put lpr in the standard place. There could be legitimate
>>> security concerns about allowing such an over-ride.
>>> Perhaps you need a port of OpenJDK to that distro which you don't name ?
>> 
>> This specifically concerns Flatpak, where it is entirely non-trivial to place files outside of the
>> /app directory. I would be interested to hear about these aforementioned security concerns.
>> Presumably if someone is able to set system properties, there are bigger problems?
> 
> Even so, no reason to make things even easier for an attacker.
> 
> Like Phil, I would feel better with a different solution. Does it really have to be freely
> configurable, can we not assume some sort of standard path? And why do we need this on Non-Linux
> platforms?

Why we need it on non-linux platforms? I'm not sure. I thought it would be reasonable to allow changing
both. Perhaps that was a mistake.

With regards to a different solution, first attempting /usr/bin/lpr and then looking up the binary on
$PATH seems like a reasonable alternative. That's what I will propose next.

> This also increases the test surface, and it would be good to have a regression test.

I agree. I'll include one.

> Cheers, Thomas



More information about the client-libs-dev mailing list