[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: Allow overriding lp and lpr binary paths in PSPrintJob
From:       "Rolf van Kleef" <rolf () vankleef ! me>
Date:       2021-10-27 8:43:16
Message-ID: 7c7b1714288e09658bf1c8376a0d3bd3 () vankleef ! me
[Download RAW message or body]

Hi Thomas,

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

> Hi Rolf,
> 
> On Tue, Oct 26, 2021 at 9:30 PM Rolf van Kleef <rolf@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
[prev in list] [next in list] [prev in thread] [next in thread]