Re: GNU Parallel Bug Reports parallel cannot cope with process with empty name

[Daniel Colascione]

On 06/26/2015 01:57 PM, Ole Tange wrote:
> On Fri, Jun 26, 2015 at 6:06 PM, Daniel Colascione <address@hidden> wrote:
>> On 06/26/2015 11:52 AM, Ole Tange wrote:
>>> On Fri, Jun 12, 2015 at 2:51 AM, Daniel Colascione <address@hidden> wrote:
>>>
>>>> It's possible for a process to have an empty name:
>>>
>>> I have seen this twice:
>>>
>>> * Once on a Mac running Cubase's license server software
>>> * Once on a Linux system that was compromised by criminals
>>>
>>>> $ ps -ef | perl -ane '1..1 and /^(.*)CO?MM?A?N?D/ and $s=length
>>>> $1;s/^.{$s}//; print "@F[1,2] $_"' | grep 900
>>>> 90029 90023
>>>
>>> Can you elaborate on what OS you are running and which crazy program
>>> removes it's program name from the process list?
>>
>> It's an internal program running a typical GNU/Linux system. The
>> program's provenance doesn't matter: it's both legal and possible for
>> programs to give themselves empty names.
> 
> Correct. Yet if most programs did that, a lot would be much harder,
> which in my opinion is crazy. It is also both legal and possible to
> rename all files and dirs to only consist of combinations of space,
> tab and newline, but I would also call that crazy:
> 
>   find . -print0 | sort -zr | parallel -0 mv {} '{=
> $a=$job->seq();$_="";@s=split//,"\t
> \n";while($a>=1){$_.=$s[$a%3];$a/=3;} =}'
> 
>> Are you suggesting it's okay
>> for Parallel to fall over and die (in a loop, no less, when executed
>> with --version) because some program uses a supported API in a way that
>> displeases you?
> 
> I am suggesting that the only situations I have seen this happen in are:
> 
> * Once on a Linux system that was compromised by criminals. In this
> instance GNU Parallel was actually the initial reason why they started
> an investigation and thereby discovered the criminals.
> 
> * Once on a Mac running Cubase's license server software. Since
> Cubase's iLok server will probably run on quite a few Macs, GNU
> Parallel now has an exception for this.
> 
> As I see the situation I will have to weigh between 2 basic scenarios:
> 
> * Keep the code as is. It has proven that it (indirectly) catches criminal 
> acts.

XKCD 1172 applies.

> * Change the code to deal nicely with a program of which I only know
> that it has a silly idea to rename itself to the empty string, and for
> all I know may be used by only a single user in the world.
> 
> If the program was widespread, then that would not be a hard choice,
> which is why I am interested to know more about the program.
> 

It's not the job of generic utilities to be intrusion detection
toolkits. In fact, this bug in Parallel made it *harder* to find the
cause of the non-malicious bug that produced this behavior, since it
broke several of my tools that rely on GNU Parallel. The fix is simple
as well, since we're just using a regular expression to match the
process list, and this regular expression can be easily adapted to.

It's not acceptable for a general-purpose utility to misbehave when a
completely unrelated process on the system has an unusual name.

signature.asc
Description: OpenPGP digital signature