Allow overriding lp and lpr binary paths in PSPrintJob

[Rolf van Kleef]

Hi,

October 26, 2021 9:45 PM, "Philip Race" <philip.race at oracle.com> wrote:

> Hi,
> Could you sign up for the mailing list ? I keep having to manually process these
> which is work as well as delay ..

I have now done that.

> And the one for this seems to have gone AWOL, not sure what happened with mailman.

I'm afraid that was my mistake. I failed to hit "reply to all", and instead replied just
to you. Sorry!

> 
> Comments below.
> 
> On 10/26/21 7:01 AM, Rolf van Kleef wrote:
> 
>> October 22, 2021 7:05 PM, "Philip Race" <philip.race at oracle.com> 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.
> 
> Mostly .. although this actually needs an approved CSR too since it introduces a new "interface"

I see. Would looking up the binary on $PATH still require this?

>>>> 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.
> 
> I see (sort of) I only recently heard of Flatpak.
> 
> I guess this also means it maybe isn't enough (even if it were OK, which I doubt it is)
> to expect that "lpr" be available on the path as a fallback to /usr/bin/lpr ?

This would be enough for Flatpak. We have full control over the path.

>> Presumably if someone is able to set system properties, there are bigger problems?
> 
> Not entirely disagreeing .. but we've had to deal with issues in the past where
> the security team had concerns with things that are sufficiently similar I'd need to get their OK

I see

>> I am very open to discussing alternative solutions.
> 
> Me too .. if I could think of any.
> Maybe we can FIRST try /usr/bin/lpr and only look at the property if the command doesn't exist ..
> That might make the security team happier because you'd need to be able to remove things
> in /usr/bin and if someone can do that then you REALLY have problems.

That makes sense. I'll suggest a new change where /usr/bin/lpr is tried first, and then the binary is
looked for on the $PATH.

> -phil.
> 
>>> -phil
>>> 
>>> On 10/22/21 5:42 AM, Rolf van Kleef wrote:
>> 
>> I am not sure about whether this is the correct list for this, or whether this is an appropriate
>> message for this list, but I have been told to send an email here regarding a PR I submitted on
>> GitHub.
>> 
>> I recently ran into trouble with printing on Linux, where the lpr binary was on a non-standard path
>> (not in /usr/bin/lpr). After looking in the code, I found out that this path cannot be overridden.
>> It seems that such paths should be able to be overriden, and so, I propose to add a system property
>> named "sun.print.lprPath" and "sun.print.lpPath" to override these paths. See the PR below.
>> 
>> https://github.com/openjdk/jdk/pull/6052
>> 
>> Regards,
>> Rolf van Kleef