[X2Go-Dev] Bug#1133: Inconsistent Perl used by server or its agent on connect

[Ted Toal]

> If you explicitly break your setup by defining random variables in shell startup
> scripts, you'll have to handle the outcome.
> 

I did not break perl, I replaced perl with a different perl, which involved adding a PATH and changing Perl env. vars.  In a sense, the real problem is that Perl finds its libraries in a stupid way.  But given that it is this way, I don’t know what the best way to deal with this situation is.  Fixing it with ‘if’ statements in .bashrc is a lousy solution, an annoyance to a lot of people.
> 
> If anything, we could explicitly unset PERL5LIB in the client application for
> additional sanitation. Would that make sense?

Yes it would.  But then I don’t know if Perl will still find the libraries it needs.  It might, because it may have the default library paths hard-coded.  I seem to remember reading that Perl puts some paths in place when it is compiled.  Maybe the Active Perl I use was not compiled correctly to get the correct default paths, and if it had been maybe I wouldn’t need to set PERL5LIB.

ted

> 
> 
> Mihai


> On Jan 11, 2017, at 12:58 AM, Mihai Moldovan <ionic at ionic.de> wrote:
> 
> Control: reassign -1 x2goserver 4.0.1.20
> 
> On 11.01.2017 02:48 AM, Ted Toal wrote:
>> perl has the -l option for specifying the PERL5LIB path.  That option can, and I think should, be used on the shebang of the x2go perl scripts:
>> 
>> #!/usr/bin/perl -l /usr/lib/perl5
>> 
>> or something like that.  I know the shebang line allows args.
> 
> If you explicitly break your setup by defining random variables in shell startup
> scripts, you'll have to handle the outcome.
> 
> Following the same line of original reasoning, users COULD potentially replace
> /usr/bin/perl with /bin/false. It's unreasonable to expect stuff to check
> whether /usr/bin/perl actually is a Perl interpreter.
> 
> 
> In your case, the proper workaround would be to change the perl hashbangs to
> "#!/usr/bin/env perl" instead, so that the first matching perl binary in $PATH
> is used. I won't change that in x2goserver, though, as we have literally no idea
> what users do to their PATH variable (and shouldn't assume.) Note, that this may
> still not work, as I vaguely remember at least X2Go Client to export a sane PATH
> value before executing any command remotely, though.
> 
> If anything, we could explicitly unset PERL5LIB in the client application for
> additional sanitation. Would that make sense?
> 
> 
> 
> Mihai
>