Glenn Fowler <gsf at research.att.com> wrote:
>
> On Thu, 16 Aug 2007 16:45:45 +0200 Joerg.Schilling at fokus.fraunhofer.de
> (Joerg Schilling) wrote:
> > James Carlson <james.d.carlson at sun.com> wrote:
>
> > Let me try to first avoid to discuss things that are arguable...
>
> > > > Don should know that there is no POSIX violation. He did not prove his
> > > > claim
> > > > with a pointer to the POSIX standard, judge yourself whom to
> > > > believe.....
> > >
> > > http://www.opengroup.org/onlinepubs/007908799/xcu/tar.html
> > >
> > > It says nothing about (mis)interpreting an absolute path name as a
> > > relative one, or about switching that behavior on or off.
>
> > Correct, it does not forbid the behavor that has been chosen to make tar
> > more
> > safe.
>
> apologies for posting to a closed case
> but I can't let this one go
> an application does not have carte blanche to do operation X simply
> because the standard does not forbid operation X
Sorry, but you are following the discussions on the OpenGroup standard
discussion list for a long time. You should know that it is the intention of
the POSIX standard to completely and unambiguously describe the intended
behavior of all utilities that are covered by the POSIX standard.
We are currently talking about something that is called "unspecified behavior"
with respect to standard terms. An application may choose any meaningful way
to deal with unspecified parts of the standard. As there is a serious problem
with archives that include files with absolute path names and as innumerable
UNIX FAQs mention not to create such archives since ~ 30 years, I see no
problem to implement archivers to be secure by default and to disallow the
extraction of files with absolute path names.
If you believe the POSIX standard leaves room for something you call unwanted,
you need to file a defect report.
> there are other complications
> suppose the archive contains the symbolic link
> /somedir/foo -> /dev/null
> does the default "tar will be safe" mode interpret this as
> ./somedir/foo -> ./dev/null
> or
> ./somedir/foo -> /dev/null
Trying to forbid absulute path names in link targets is a bad idea. This has
been overruled 18 years ago.
If you believe that removing slashes from the beginning of absolute path names
is a bad idea and if you are able to give good reasons for this, I am willing
to negotiate a different behavior. This could be e.g. _skipping_ the extraction
of these files instead of making the path name a relative path. I am alway open
for constructive discussions...
Note that star already _skips_ the extraction of files with "/../" in the path
name unless -.. has been specified.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
