commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philipp Knobel (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (COMPRESS-278) Incorrect handling of NUL username and group Tar.gz entries
Date Fri, 18 Apr 2014 16:11:28 GMT

     [ https://issues.apache.org/jira/browse/COMPRESS-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Philipp Knobel updated COMPRESS-278:
------------------------------------

    Description: 
With version 1.8 of commons-compress it's no longer possible to decompress  files from an
archive if the archive contains entries having null (or being empty?) set as username and/or
usergroup. With version 1.7 this still worked now I get this exception:

{code}
java.io.IOException: Error detected parsing the header
	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:249)
	at TestBed.AppTest.extractNoFileOwner(AppTest.java:30)
Caused by: java.lang.IllegalArgumentException: Invalid byte 32 at offset 7 in '       {NUL}'
len=8
	at org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:134)
	at org.apache.commons.compress.archivers.tar.TarUtils.parseOctalOrBinary(TarUtils.java:173)
	at org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:953)
	at org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:940)
	at org.apache.commons.compress.archivers.tar.TarArchiveEntry.<init>(TarArchiveEntry.java:324)
	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:247)
	... 27 more

{code}
This exception leads to my suspision that the regression was introduced with the fix for this
ticket COMPRESS-262, which has a nearly identical exception provided.

Some test code you can run to verify it:

{code}
package TestBed;

import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;

import org.apache.commons.compress.archivers.tar.TarArchiveEntry;
import org.apache.commons.compress.archivers.tar.TarArchiveInputStream;
import org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream;
import org.junit.Test;

/**
 * Unit test for simple App.
 */
public class AppTest
{

    @Test
    public void extractNoFileOwner()
    {
        TarArchiveInputStream tarInputStream = null;

        try
        {
            tarInputStream =
                new TarArchiveInputStream( new GzipCompressorInputStream( new FileInputStream(
new File(
                    "/home/pknobel/redis-dist-2.8.3_1-linux.tar.gz" ) ) ) );
            TarArchiveEntry entry;
            while ( ( entry = tarInputStream.getNextTarEntry() ) != null )
            {
                System.out.println( entry.getName() );
                System.out.println(entry.getUserName()+"/"+entry.getGroupName());
            }

        }
        catch ( FileNotFoundException e )
        {
            e.printStackTrace();
        }
        catch ( IOException e )
        {
            e.printStackTrace();
        }
    }

}
{code}
With 1.7 the TestCase outputed this:

{code}
redis-dist-2.8.3_1/bin/
/
redis-dist-2.8.3_1/bin/redis-server
jenkins/jenkins
redis-dist-2.8.3_1/bin/redis-cli
jenkins/jenkins
{code}

With 1.8 it's failing once it reaches the null valued entry, which is the first. The archive
is created using maven assembly plugin, and I tried the same with maven ant task. Both generating
an archive with not set username and groups for at least some entries.

You can download the archive from http://heli0s.darktech.org/redis/2.8.3_1/redis-dist-2.8.3_1-linux.tar.gz

If you run a tar -tvzf on the file you see this report:

{code}
drwxr-xr-x 0/0               0 2014-04-18 09:43 redis-dist-2.8.3_1-SNAPSHOT/bin/
-rwxr-xr-x pknobel/pknobel 3824588 2014-01-02 14:58 redis-dist-2.8.3_1-SNAPSHOT/bin/redis-cli
-rwxr-xr-x pknobel/pknobel 5217234 2014-01-02 14:58 redis-dist-2.8.3_1-SNAPSHOT/bin/redis-server
{code}

The user 0/0 probably indicates that it's not set although it's the root user id. A correctly
root user file would show up as root/root

  was:
With version 1.8 of commons-compress it's no longer possible to decompress  files from an
archive if the archive contains entries having null (or being empty?) set as username and/or
usergroup. With version 1.7 this still worked now I get this exception:

{code}
java.io.IOException: Error detected parsing the header
	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:249)
	at TestBed.AppTest.extractNoFileOwner(AppTest.java:30)
Caused by: java.lang.IllegalArgumentException: Invalid byte 32 at offset 7 in '       {NUL}'
len=8
	at org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:134)
	at org.apache.commons.compress.archivers.tar.TarUtils.parseOctalOrBinary(TarUtils.java:173)
	at org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:953)
	at org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:940)
	at org.apache.commons.compress.archivers.tar.TarArchiveEntry.<init>(TarArchiveEntry.java:324)
	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:247)
	... 27 more

{code}
This exception leads to my suspision that the regression was introduced with the fix for this
ticket COMPRESS-262, which has a nearly identical exception provided.

Some test code you can run to verify it:

{code}
package TestBed;

import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;

import org.apache.commons.compress.archivers.tar.TarArchiveEntry;
import org.apache.commons.compress.archivers.tar.TarArchiveInputStream;
import org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream;
import org.junit.Test;

/**
 * Unit test for simple App.
 */
public class AppTest
{

    @Test
    public void extractNoFileOwner()
    {
        TarArchiveInputStream tarInputStream = null;

        try
        {
            tarInputStream =
                new TarArchiveInputStream( new GzipCompressorInputStream( new FileInputStream(
new File(
                    "/home/pknobel/redis-dist-2.8.3_1-linux.tar.gz" ) ) ) );
            TarArchiveEntry entry;
            while ( ( entry = tarInputStream.getNextTarEntry() ) != null )
            {
                System.out.println( entry.getName() );
                System.out.println(entry.getUserName()+"/"+entry.getGroupName());
            }

        }
        catch ( FileNotFoundException e )
        {
            e.printStackTrace();
        }
        catch ( IOException e )
        {
            e.printStackTrace();
        }
    }

}
{code}
With 1.7 the TestCase outputed this:

{code}
redis-dist-2.8.3_1/bin/
/
redis-dist-2.8.3_1/bin/redis-server
jenkins/jenkins
redis-dist-2.8.3_1/bin/redis-cli
jenkins/jenkins
{code}

With 1.8 it's failing once it reaches the null valued entry, which is the first. The archive
is created using maven assembly plugin, and I tried the same with maven ant task. Both generating
an archive with not set username and groups for at least some attributes.

You can download the archive from http://heli0s.darktech.org/redis/2.8.3_1/redis-dist-2.8.3_1-linux.tar.gz

If you run a tar -tvzf on the file you see this report:

{code}
drwxr-xr-x 0/0               0 2014-04-18 09:43 redis-dist-2.8.3_1-SNAPSHOT/bin/
-rwxr-xr-x pknobel/pknobel 3824588 2014-01-02 14:58 redis-dist-2.8.3_1-SNAPSHOT/bin/redis-cli
-rwxr-xr-x pknobel/pknobel 5217234 2014-01-02 14:58 redis-dist-2.8.3_1-SNAPSHOT/bin/redis-server
{code}

The user 0/0 probably indicates that it's not set although it's the root user id. A correctly
root user file would show up as root/root


> Incorrect handling of NUL username and group Tar.gz entries
> -----------------------------------------------------------
>
>                 Key: COMPRESS-278
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-278
>             Project: Commons Compress
>          Issue Type: Bug
>    Affects Versions: 1.8
>            Reporter: Philipp Knobel
>
> With version 1.8 of commons-compress it's no longer possible to decompress  files from
an archive if the archive contains entries having null (or being empty?) set as username and/or
usergroup. With version 1.7 this still worked now I get this exception:
> {code}
> java.io.IOException: Error detected parsing the header
> 	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:249)
> 	at TestBed.AppTest.extractNoFileOwner(AppTest.java:30)
> Caused by: java.lang.IllegalArgumentException: Invalid byte 32 at offset 7 in '     
 {NUL}' len=8
> 	at org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:134)
> 	at org.apache.commons.compress.archivers.tar.TarUtils.parseOctalOrBinary(TarUtils.java:173)
> 	at org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:953)
> 	at org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:940)
> 	at org.apache.commons.compress.archivers.tar.TarArchiveEntry.<init>(TarArchiveEntry.java:324)
> 	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:247)
> 	... 27 more
> {code}
> This exception leads to my suspision that the regression was introduced with the fix
for this ticket COMPRESS-262, which has a nearly identical exception provided.
> Some test code you can run to verify it:
> {code}
> package TestBed;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.FileNotFoundException;
> import java.io.IOException;
> import org.apache.commons.compress.archivers.tar.TarArchiveEntry;
> import org.apache.commons.compress.archivers.tar.TarArchiveInputStream;
> import org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream;
> import org.junit.Test;
> /**
>  * Unit test for simple App.
>  */
> public class AppTest
> {
>     @Test
>     public void extractNoFileOwner()
>     {
>         TarArchiveInputStream tarInputStream = null;
>         try
>         {
>             tarInputStream =
>                 new TarArchiveInputStream( new GzipCompressorInputStream( new FileInputStream(
new File(
>                     "/home/pknobel/redis-dist-2.8.3_1-linux.tar.gz" ) ) ) );
>             TarArchiveEntry entry;
>             while ( ( entry = tarInputStream.getNextTarEntry() ) != null )
>             {
>                 System.out.println( entry.getName() );
>                 System.out.println(entry.getUserName()+"/"+entry.getGroupName());
>             }
>         }
>         catch ( FileNotFoundException e )
>         {
>             e.printStackTrace();
>         }
>         catch ( IOException e )
>         {
>             e.printStackTrace();
>         }
>     }
> }
> {code}
> With 1.7 the TestCase outputed this:
> {code}
> redis-dist-2.8.3_1/bin/
> /
> redis-dist-2.8.3_1/bin/redis-server
> jenkins/jenkins
> redis-dist-2.8.3_1/bin/redis-cli
> jenkins/jenkins
> {code}
> With 1.8 it's failing once it reaches the null valued entry, which is the first. The
archive is created using maven assembly plugin, and I tried the same with maven ant task.
Both generating an archive with not set username and groups for at least some entries.
> You can download the archive from http://heli0s.darktech.org/redis/2.8.3_1/redis-dist-2.8.3_1-linux.tar.gz
> If you run a tar -tvzf on the file you see this report:
> {code}
> drwxr-xr-x 0/0               0 2014-04-18 09:43 redis-dist-2.8.3_1-SNAPSHOT/bin/
> -rwxr-xr-x pknobel/pknobel 3824588 2014-01-02 14:58 redis-dist-2.8.3_1-SNAPSHOT/bin/redis-cli
> -rwxr-xr-x pknobel/pknobel 5217234 2014-01-02 14:58 redis-dist-2.8.3_1-SNAPSHOT/bin/redis-server
> {code}
> The user 0/0 probably indicates that it's not set although it's the root user id. A correctly
root user file would show up as root/root



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message